5 ms·

Erm, this does not actually seem to work on Centos7, running systemd-219-19.el7_2.13. Even tried it as root inside of a sandbox - nothing.

• lake99 10y ago
  It's the same on Archlinux, systemd-231. Nothing happened. I was able to start and stop a couple of services as quickly as before.
• SysArchitect 10y ago
  while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done Try this. As soon as you loop it, the bug is hit pretty quickly.
  • deleted 10y ago
    [deleted]
  • nilved 10y ago
    I don't understand why that makes a difference if the bug is `assert(n > 0)`
    • SysArchitect 10y ago
      I have no idea either. Race condition somewhere? It was mentioned here: https://github.com/systemd/systemd/issues/4234 https://github.com/systemd/systemd/issues/4234
    • JdeBP 10y ago
      There is a race in the systemd-notify mechanism that means that some notification messages get discarded if the systemd-notify process happens to complete its work and exit before systemd picks up the message. They never reach the point of the assertion that is triggered here, because systemd is unable to determine the service unit that encompasses the message sender. * http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#SynchronousProtocol http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems...
• agwa 10y ago
  Hmmm... I've repro'd on v215, v229, and v230, although only on Debian and Ubuntu. The bug has been in systemd upstream since v209 as far as I can tell by reading the code.
  • deleted 10y ago
    [deleted]