
How to Crash Systemd in One Command - agwa
https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
======
justin_vanw
It seems like it is quite fashionable to hate on systemd, and it seems like
systemd is kindof a piece of crap - in some ways.

However, linux is missing basic functionality other os's offer, and systemd is
showing up and trying to fill in those blanks. This is open source, if you
don't like systemd, if you think it's crap, if you think there are obviously
better ways to do it, well, what are you waiting for then?

Systemd is winning because they showed up and basically nobody else did. It's
open source fork it and 'do it right'. Or point out the problems and hope that
someone else will step up instead?

I think the world would better place if people spent less time griping and
more time fighting to get their patch that fixes the problems merged. I guess
coding is harder than writing blog posts though.

EDIT: I'm not saying systemd is perfect or even good. My point is that the
people writing the code are going to have the final say, whether it's right or
wrong, and it is unlikely that people writing blog posts lampooning it are
really going to make a difference. I mean systemd has been despised and highly
criticized from the beginning, and look where we are.

~~~
lasermike026
The Unix philosophy: Write programs that do one thing and do it well.

Systemd doesn't observe the Unix philosophy and that bothers many people.

~~~
geofft
It's baffling to see people insist that that's the UNIX philosophy when the
UNIX philosophy has always been about monolithic kernels over microkernels, so
"do one thing" is out the window, and about worse-is-better over do-the-right-
thing
([https://www.dreamsongs.com/RiseOfWorseIsBetter.html](https://www.dreamsongs.com/RiseOfWorseIsBetter.html)),
so "do it well" is out the window.

And the userspace tools don't follow this either. Quoting
[http://prog21.dadgum.com/139.html](http://prog21.dadgum.com/139.html) :

> _The UNIX ls utility seemed like a good idea at the time. It 's the poster
> child for the UNIX way: a small tool that does exactly one thing well. Here
> that thing is to display a list of filenames. But deciding exactly what
> filenames to display and in what format led to the addition of over 35
> command-line switches. Now the man page for the BSD version of ls bears the
> shame of this footnote: "To maintain backward compatibility, the
> relationships between the many options are quite complex."_

Why, for instance, does ls have its own sorting options if the sort command
exists? If ls, the most quintessential UNIX command, can't do one thing and do
it well, why should anything else?

~~~
lasermike026
The Unix philosophy is most applicable in user space. It's a philosophy not a
law. I didn't say Systemd was bad just that it doesn't observe the Unix
philosophy.

Crashing an init process is a very bad thing, is it not? Wouldn't less surface
area be a better approach?

~~~
geofft
Yes, I argued in another comment that it would be a good idea to split systemd
into two processes, where PID 1 does nothing other than reap children, send
info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to
make sense for PID 2 to be as monolithic as systemd currently is (which is not
very monolithic; udev, journald, D-Bus, etc. are separate daemons).

~~~
JdeBP
That's a common misconception. The major task of process #1 with modern
kernels is not, ironically, reaping children but receiving signals. Reaping
orphaned children can be, and with several softwares is, the job of other
processes.

* [https://news.ycombinator.com/item?id=8904429](https://news.ycombinator.com/item?id=8904429)

* [http://unix.stackexchange.com/a/197472/5132](http://unix.stackexchange.com/a/197472/5132)

* [https://news.ycombinator.com/item?id=8384251](https://news.ycombinator.com/item?id=8384251)

* [http://unix.stackexchange.com/a/177361/5132](http://unix.stackexchange.com/a/177361/5132)

~~~
geofft
That makes no sense. Who's sending SIGWINCH to pid 1? Is it in a tty? Why is
it in a tty? Why does it care about the size of its window?

It is true that _the userspace helper programs of some init system suites_ ,
such as sysvinit's telinit, work by sending signals to pid 1. But 1) they send
signals to pid 1 because pid 1 is the service manager, not because it's the
system manager, and 2) they could do something else other than sending signals
(like sending D-Bus messages). The choice to use signals is a design decision
of the init system suite, and not a part of the inherent requirements of being
pid 1.

It is also true that with prctl(PR_SET_CHILD_SUBREAPER) you can move reaping
away from pid 1. But at that point, the proper function of pid 1 is _nothing_
, except perhaps to respawn pid 2 if it wants to. And as I argued in the other
comment in this thread
[https://news.ycombinator.com/item?id=12600734](https://news.ycombinator.com/item?id=12600734),
that's silly and you should just make the kernel do it.

I don't see any explanation in any of those links, or the things they link to,
about why pid 1 is receiving signals. You claim twice that SIGINT, SIGPWR, and
SIGWINCH are things that pid 1 can receive, but I have no idea why it might
receive them. Can you explain?

~~~
JdeBP
It's explained two times over, and they are indeed system state controls, not
service state controls.

You are exemplifying the people with off-the-top-of-the-head designs for init
that I mentioned. The signals to process #1 from the kernel are rarely
included, or even thought of, in such designs; despite the fact that they are
the things that a process #1 program cannot escape and the child reaping is
actually the least of its work and the thing that it can mostly escape. Here
you are with yet another off-the-top-of-the-head design being thrashed out in
a discussion forum, and you have not even encountered this stuff to know that
a design has to include it, as evidenced by the questions about TTYs and
windows.

As I said, go and look at many _actual_ process #1 programs, such as Gerrit
Pape's runit, Felix von Leitner's minit, and the system-manager program from
the nosh package. They all have to handle these signals, and they all do.
Don't repeat ... ahem! ... some other people's mistake of not learning about
existing softwares and mechanisms.

The nosh system-manager and systemd both discuss them in their manual pages.
They both have an explicit list of signals and what they trigger. The manual
for /etc/inittab in van Smoorenburg init also discusses these signals and what
they are, as do the manual for Joachim Nilsson's finit
([http://troglobit.com/finit.html](http://troglobit.com/finit.html)) and its
TODO list.

I recommend some manual reading. (-:

~~~
geofft
OK, I went and learned some things and it turns out I was wrong but (at least
assuming Linux, which is fair since this is a thread about systemd) you're
wrong too. None of these signals have to be handled by pid 1.

SIGWINCH for a keyboard request is a thing that I did not know about, yes. But
this is opt-in functionality for any process that has any VT open and is
suitably privileged, and it is simply traditional for init to call ioctl(0,
KDSIGACCEPT, SIGWINCH). Any process can request this, not just init; any
signal can be used, not just SIGWINCH. And by default, no signal gets sent,
neither to init nor to any other process. So init does not need to handle it.

(This of course leaves aside the question of whether anyone uses this
functionality. How many users who are _not_ init system developers know about
this? And how many people have machines with physical keyboards that are not
just running some window system that puts the keyboard in raw mode, anyway?)

See
[https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/k...](https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/keyboard.c#L98-L102)
and L593-602 (initialized to 0 and disabled by default),
[https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/v...](https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/vt_ioctl.c#L578-L592)
(KDSIGACCEPT ioctl allows any suitably privileged process to request this),
and [http://www.fifi.org/doc/console-tools-
dev/examples/spawn_log...](http://www.fifi.org/doc/console-tools-
dev/examples/spawn_login.c) (a separate daemon for doing this - via SIGHUP,
incidentally - which says, "Note: this functionality has become part of init",
implying it was originally _not_ part of init!).

SIGINT on Ctrl-Alt-Del (if reboot(LINUX_REBOOT_CMD_CAD_OFF) has been called),
and SIGPWR on power failure from the two drivers that implement it, are sent
via the kill_cad_pid() function. This _does_ default to pid 1, but that's just
a default. And it's very easy to change that setting in userspace; it's a
sysctl, /proc/sys/kernel/cad_pid.

See
[https://github.com/torvalds/linux/blob/v4.7/init/main.c#L998](https://github.com/torvalds/linux/blob/v4.7/init/main.c#L998),
which defaults cad_pid to init, and
[https://github.com/torvalds/linux/blob/v4.7/kernel/sysctl.c#...](https://github.com/torvalds/linux/blob/v4.7/kernel/sysctl.c#L2666-L2686),
the sysctl implementation.

The two drivers that implement SIGPWR, incidentally, are the S390 NMI handler
and the SGI SN Platform's system controller driver, both of which I'm pretty
sure see no use today. It's usually sent by a userspace process these days,
which again could just choose to not use signals.

So none of the signals you've mentioned are pid 1's responsibility, They are
_traditionally_ pid 1's responsibility, yes. But those are two very different
things, especially if we're talking about using PR_SET_CHILD_SUBREAPER to move
all the interesting work out of pid 1.

The remainder of the signals handled by sysvinit, finit, runit, and nosh are
all generated by userspace, and minit handles no other signals. And not all of
these init systems bother to call KDSIGACCEPT.

I recommend being less condescending, especially if you're going to be wrong.
(-:

------
rcarmo
First they came for PID 1, and we were silent.

Oh, wait, we weren't. But although I don't miss the rickety init scripts, I've
grown more and more worried about stuff like this, enough to ponder
replacements (in Go or Python, which seem to be generally acceptable for
systems software these days).

Ignoring for the moment the usual biases against Python, how feasible/how much
support would it be/have to build something to replace systemd (by having PID
1 do the minimum possible, in C, and having the rest done with Python)?

~~~
djsumdog
I've been working at a Docker shop for a while and I have a feeling it will be
the future for running services. It makes systemd somewhat irrelevant.

There are still a lot of issues I've had with Docker, which I won't go into.
It also can't replace everything running on your Linux system. But it's a neat
idea and big players use it in production for huge workloads.

Now the whole AWS-containers, docker-machine, swarm, mesos, coreos, kubernetes
thing is a cluster fuck of choices .. but you have choices. And unlike running
an Ansible script on some provides base image (which is totally different from
Rackspace, Linode, etc.), you are guaranteed your container will work on any
docker engine with little modification (your orchestration files may change
though).

I have a feeling, for better or worse, containers will be the future and will
stick around long after systemd hopefully dies.

~~~
digi_owl
Nah, systemd is angling to supplant docker for containers.

There is already a great deal of bad blood between the two because of the
reworked cgroups management.

And there is also the likes of CoreOS that is basically systemd-the-distro.

Never mind that we have the likes of xdg-app/flatpak that is basically aiming
for what you are thinking about, and it is systemd dependent.

~~~
fridsun
It was quite amusing seeing systemd causing systemd-specific trouble in CoreOS
development though, such as systemd requiring too much privilege when running
inside container. Many people just use s6 happily.

~~~
digi_owl
The schadenfreude is real.

------
wyldfire
> The immediate question raised by this bug is what kind of quality assurance
> process would allow such a simple bug to exist for over two years (it was
> introduced in systemd 209). Isn't the empty string an obvious test case?

All bugs are terribly easy to spot in hindsight. I don't think it's fair to
criticize this one in that fashion. Systemd has lots of pros and cons, but the
age of this bug isn't interesting IMO. Its severity is, but that only speaks
to the critical need to patch it ASAP.

------
milankragujevic
Archived page, since it's not loading for me...
[http://archive.is/8xUSY](http://archive.is/8xUSY)

~~~
agwa
My hosting provider thought I was under DDoS attack and started aggressively
throttling port 443. I failed over to my backup provider, probably
permanently.

------
SysArchitect
The issue has a bug report on the systemd repo on Github:
[https://github.com/systemd/systemd/issues/4234](https://github.com/systemd/systemd/issues/4234)

------
xemdetia
At this point in time my biggest frustration is that even compared to upstart
writing concise and clear config files for network services is just really
hard, and there isn't great documentation or a short book around that covers
all the edge cases other than TIAS. I feel like I've wasted more time trying
to get a tidy systemd configuration than I ever had even with upstart or some
of the other ones.

------
redbeard0x0a
This article got me wondering if maybe the NSA or similar has somebody on the
inside of the systemd project that is helping the project along.

Systemd has replaced a lot of init systems in the linux ecosystem and the
general development practices of the project is leaving a huge footprint of
code that might be exploited.

If they aren't involved, I'm sure they probably know a few different exploits
for the system already.

~~~
pdkl95
If you want to go down that rabbit hole, see:

[https://igurublog.wordpress.com/2014/02/17/biography-of-a-
cy...](https://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-
and-how-cryptography-affects-your-life/)

------
belovedeagle
This is an excellent writeup explaining without hysterics why systemd is
terrible software. Unfortunately, I expect that this post will be brigaded by
systemd-apologists anyways, denying newcomers to the debate the opportunity to
hear the facts...

~~~
andrewstuart2
I'm not sure how this comment is helpful to the discussion. As far as I can
tell, you'd rather _only_ hear the facts that fit your opinion of systemd as
terrible software. I think the obvious right answer is that both sides present
only facts and let newcomers decide based on that.

~~~
belovedeagle
As the other reply said, the problem is that newcomers aren't allowed to hear
the anti-systemd facts, as the systemd gods have already decided that all
Linux users (or at least all distros) must bow down and accept them, and no
dissenting opinion is allowed to stay on the front page of HN for long (this
post has already been brigaded off the front page, apparently).

~~~
fapjacks
It could be the "controversial topic" penalty, which is extremely heavy-
handed. But I also notice that both anti-systemd and pro-other-init-system
posts and comments are barraged with downvotes on all kinds of forums,
including HN. It is definitely something that certain people don't want out in
the world.

------
geofft
I've been thinking for a bit that it's reasonably easy to write a PID 1 that
reaps children and sends siginfo_t structs over a pipe to PID 2, which can be
an init system as monolithic as you want.

Of course, it would _also_ be simple for the kernel to allow PID 1 to
die/crash, and just restart it instead of panicking. I don't know why the
kernel continues to treat PID 1 so specially—if the ewontfix.com PID 1 is
sufficient, it's _simpler_ for the kernel not to bother with the reparenting
logic and stop treating PID 1 as a special process.

~~~
mschuster91
> I don't know why the kernel continues to treat PID 1 so specially

By design all processes inherit from PID 1 (directly or indirectly), so you
always have an unbroken tree from every process back to PID 1. PID1 aka init
is supposed to do bookkeeping (e.g. zombie processing), and if PID1 crashes
the bookkeeping records are lost.

Because of this, it is better to fail hard, instead of allowing for corrupted
process trees or similar.

Also, ps, top and basically every program that works with processes expects
one root process for the tree. Breaking this would basically break
compatibility with every existing userland (which the kernel cares the most
about!)

~~~
justinsaccount
> Breaking this would basically break compatibility with every existing
> userland

By "Breaking this" you mean "fixing the fact that pid 1 can't crash and
restart"?

> Because of this, it is better to fail hard

It can't be fixed because it would "break compatibility" where that
"compatibility" is that the machine should panic?

You're not really making a good case for why this can't be changed.

Why not

    
    
      * pid 1 exits
      * kernel re-executes init as a new pid 1
      * userspace continues on as if nothing happened.

~~~
geofft
Right. If init opts into it, e.g. by setting some sysctl or something, the
kernel changes behavior in the following way:

1\. Processes that are reparented to init aren't actually considered children
of init for the purposes of the wait() system call. Their ppid still becomes
1, so parent process walks work, but when they exit, the kernel immediately
cleans them up.

Zombies still exist in this change, as long as their parent still exists; the
only thing that changes is that processes (zombies or not) are not reparented
to init when their parent dies. Direct children of pid 1 are not treated
specially.

2\. When init is about to exit or crash, the kernel turns it into a zombie. It
then starts a new init process and reparents the old init to the new one,
allowing it to do things depending on the cause of the crash. Direct children
of the old init have lost their parent, and are treated like any other
parentless process as described above.

3\. If execing the new init fails, the kernel panics.

This would be completely backwards-compatible. (I might even argue against 3,
to remove all worry about init crashing; since pid 1 is no longer required to
do anything, if exec fails, the kernel can just leave pid 1 as a stuck process
table entry, let the system continue running, and log something to dmesg so
the sysadmin can diagnose the problem and reboot the machine cleanly.)

~~~
justinsaccount
Sounds reasonable. Any ideas why no one has ever done this?

Kind of reminds me when the behavior of rm -rf / was changed in solaris.

I can't find the article, but basically someone pointed out that they couldn't
change the behavior of rm -rf / because posix defined how it should work.
Someone then pointed out that the spec says that trying to remove the parent
directory(i think?) should fail, and since rm -rf / includes removing the
parent directory, it was within the spec that it should fail.

------
JdeBP
Lennart Poettering's response to this was interesting:

> _The bug is caused by an error check that filters out garbage sent to PID 1.
> The check works correctly, except that the resulting action is a too harsh:
> instead of complaining and dropping it will abort the process._

* [https://www.reddit.com/r/linux/comments/54yfcd/how_to_crash_...](https://www.reddit.com/r/linux/comments/54yfcd/how_to_crash_systemd_in_one_tweet/d86rs74)

In fact, the opposite was the case. The root of the problem was identified in
the GitHub bug report:

* [https://github.com/systemd/systemd/issues/4234#issuecomment-...](https://github.com/systemd/systemd/issues/4234#issuecomment-250431337)

* h[https://github.com/systemd/systemd/commit/d875aa8ce10b458dc2...](https://github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03)

What happened was that Lennart Poettering _removed an error check_ that
filtered out zero-length messages. This left the flow of control to fall
through to a later point where an assertion, that had been earlier added by
Lennart Poettering with the assumption that this check for zero was in place
(as it had been at the time), then triggered.

Of course, no-one that I have seen has yet asked why "" as a command-line
argument to systemd-notify results in a zero-length message in the first
place. After all, according to the doco that would be length 1, a single
terminating LF byte, not zero length. That said, the server still should be
proof against zero-length network input.

------
aorth
A CVE has been requested, albeit after publication of the bug:

[http://www.openwall.com/lists/oss-
security/2016/09/28/9](http://www.openwall.com/lists/oss-
security/2016/09/28/9)

~~~
JdeBP
Discussed on Hacker News at
[https://news.ycombinator.com/item?id=12600994](https://news.ycombinator.com/item?id=12600994)
.

------
fridsun
Lennart Poettering has replied on Reddit.

[https://www.reddit.com/r/linux/comments/54yfcd/how_to_crash_...](https://www.reddit.com/r/linux/comments/54yfcd/how_to_crash_systemd_in_one_tweet/d86rs74)

> So let's summarize this. There's a bug in some software. OMG! Shock! This of
> course never happened before!

> The bug is in not exploitable remotely. The bug does not allow privilege
> escalation nor insertion of code. This of course makes the bug a massive
> vulnerability like there was no other on the planet ... ever. As bad as
> heartbleed multiplied by the Debian OpenSSL random generator bug to the
> power of 10.

> The bug is caused by an error check that filters out garbage sent to PID 1.
> The check works correctly, except that the resulting action is a too harsh:
> instead of complaining and dropping it will abort the process. Such a bug is
> of course unprecedented and the authors of said software should be stoned
> and flogged right away given the severity of the issue: after all a safety
> check worked a bit too well, and we really can't have that because undefined
> behaviour of course would be a lot better than a local DoS.

> The project the error was found in is large. Yet the number of CVEs collect
> so far is pretty small comparing it witht other projects of similar extent.
> Given that another bug was discovered now this obviously shows how
> incompetent the programmers are and that security is a unknown concept to
> them.

> The program the bug was found in is longer than 50 lines of code but runs
> with privileges, all written in a low-level programming langauge that many
> call little more than a fancy macro assembler. The code runs on top of an
> operating system kernel written in the same language but running with a lot
> higher privileges and consisting of expoentially more lines of code
> including drivers of questionnable quality. This together is of course proof
> that the project at hand is flawed conceptually to its core.

> Dha!

> Lennart

> (More seriously: yes this is a bug, we should fix it. But it's very low
> impact and the bruhaha it generated appears wildly out of scale. If all bugs
> in the wider Open Source ecosystem would have a similarly low impact we'd
> live in a much much safer world!)

------
m45t3r
You could simple do a DoS attack with a local user using a fork bomb too. It
would be even shorter than the command showed in this post blog.

So while this is a bug, the author is overreacting just to make systemd look
bad.

~~~
rascul
your fork bomb can be mitigated with ulimit

~~~
m45t3r
I am not saying that this is not a bug, just that this isn't the problem that
the author is making. If you have local access, you probably can do other
things if your only objective is to do a DoS.

~~~
reactor4
Your point is covered in the article.

"If you think systemd doesn't need privilege separation because it only parses
messages from local users, keep in mind that in the Internet era, local
attacks tend to acquire remote vectors. Consider Shellshock, or the
presentation at this year's systemd conference which is titled "Talking to
systemd from a Web Browser.""

------
5ilv3r
Ran as a normal user on debian jessie, and now ssh logins are delayed by 30
seconds. I don't see any other problems yet, but this is a VM host and so
leave it running for a while for fun. :)

~~~
aorth
Ran it on an up to date Ubuntu 16.04 and lost the ability to run any systemctl
commands like status, restart, etc. Web server and other system services were
still working, but I couldn't `reboot` or `systemctl halt` etc... had to hard
reboot the VPS from hosting console. :)

~~~
andreyv
"systemctl reboot --force --force" should work in such cases. The reboot will
be executed by systemctl itself.

------
JdeBP
It's interesting to see a "hacker" discussion of this that entirely misses
several topics that one would expect programmers to at least mention:

* Whether release builds should have assert() enabled.

* Whether a process #1 program should use assertions at all.

* Whether assert() is the right mechanism to use for input validation.

* How a process #1 program should recover from assertion failures.

------
xaduha
Don't really care about that bug, it will be fixed I'm sure. But thank you for
this post anyway, the word LLMNR caught my eye, very nice to have if it works.

EDIT: works fine with Windows, without installing Bonjour/iTunes.

------
tcoppi
> "Systemd is defective by design."

The most succinct explanation of Systemd possible.

~~~
mSparks
I've complained a few times that systemd haters havent explained the hate.

having read this post I'd say a slightly less succinct but infinitely more
informative version would be

> "Systemd is defective by design because they totally disregard the fail-safe
> by design rules"

~~~
qwertyuiop924
Yes. I wish people would explain their hatred. I understand that there are
valid reasons to hate systemd, which is why I avoid it like the plague. But so
many people get sucked in by the initial usefulness, and don't see the
problems lurking beneath the surface.

~~~
fapjacks
Yes, a large part of which is the _process_ behind systemd. You're adopting
more than just software when you adopt software, and I think investigating
what the systemd developers are like is a worthy exercise -- in particular how
they approach bugs. I think most people would be surprised to learn what that
is like.

~~~
qwertyuiop924
Ah, yes: When is a bug not a bug? According to the systemd developers, it's
when we don't encounter it on our personal machines.

~~~
fapjacks
... And also when they can pass the buck to kernel developers, even when it's
not a kernel bug.

~~~
digi_owl
Reminds me that i ran into an email chain a while back where the kernel devs
pondered forking or taking over udev development because they were tired of
power games from the maintainer. This was from back before udev became part of
systemd btw.

~~~
qwertyuiop924
Greg-KH is both one of the original developers on udev and a major force
behind systemd. He maintains -stable on the linux kernel.

So either the kerbel devs did take over udev development...

~~~
digi_owl
I do wonder if the kernel will split between GregKH and T'so once Torvalds
steps down.

BTW GKH was oddly absent in that thread, and the kernel devs ire was aimed at
Sievers...

~~~
qwertyuiop924
Well, GKH is One Of Them. He's less likely to attract their ire, and if he
does, at the end of the day, they have to answer to him.

But in a fight between GKH and T'so, I'll take T'so. /dev/random's
...interesting design aside, I frankly trust T'so far more than I trust GKH,
who backs LP, a person I emphatically do _not_ trust, in a lot of things.

------
bitmapbrother
>Despite the banality, the bug is serious, as it allows any local user to
trivially perform a denial-of-service attack against a critical system
component.

Is it really that serious of a bug? You have to be a local user in order to
execute it. Are other OS's somehow resilient to the actions of local user to
degrade the OS?

>The Linux ecosystem has fallen behind other operating systems in writing
secure and robust software. While Microsoft was hardening Windows and Apple
was developing iOS, open source software became complacent.

He must be unaware of the numerous patches Microsoft and Apple issue on a
regular basis to fix their "secure and robust software".

~~~
falcolas
Any remote code execution bug can exploit this. Normally, a remote execution
code bug when the user is non-root isn't a huge issue, because the user
effectively sandboxes them away. This bypasses all of these benefits.

Containers may prove to be a sufficient sandbox, assuming this is not
executable against kdbus (which is shared across containers since it's in the
kernel).

------
packetized
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.

~~~
SysArchitect

      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.

~~~
nilved
I don't understand why that makes a difference if the bug is `assert(n > 0)`

~~~
JdeBP
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...](http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#SynchronousProtocol)

------
walter_bishop
Doesn't work here on Ubuntu 16.04 xenial

~~~
Twirrim
I've put a comment on the github bug with an updated PoC. IT does work on
16.04, but you seem to have to do it over and over until it triggers. A
working PoC seems to be:

while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done

------
zzxxmm11aajj
Note: 112 comments from the peanut gallery before someone looked at the code
enough to submit the trivial fix.

