
Systemd has 6 service startup notification types, and they're all wrong - pmarin
http://ewontfix.com/15
======
zimbatm
Just add sd_notify, it's 65 lines of C code plus a couple of includes. I
implemented in pure ruby with no problem either. See for yourself:
[http://cgit.freedesktop.org/systemd/systemd/tree/src/libsyst...](http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-
daemon/sd-daemon.c#n381)

My biggest gripe is with socket activation. Systemd doesn't provide any info
apart from the file descriptors to the application so binding to port 80 and
443, you have to know the order to add SSL on the right one.

~~~
cthalupa
Some of the complaints about sd_notify is that it is just an implementation on
top of $NOTIFY_SOCKET.... which is completely undocumented. So you have a
decently documented and small implementation by Lennart that relies on
something that might as well be hoodoo magic unless you've gone through the
undocumented code.

There's also problems with nscd as pointed out in the comments, but the FSF is
insane enough in general that I don't think that's necessarily a problem with
systemd and more of an issue with working around the labyrinth of bullshit
that is the FSF and their policies.

~~~
BlackFingolfin
But $NOTIFY_SOCKET and how to use it _is_ documented, see here:
[http://0pointer.de/public/systemd-
man/sd_notify.html](http://0pointer.de/public/systemd-man/sd_notify.html)

~~~
cthalupa
???

That is documentation on sd_notify, which is an implementation that utilizes
$NOTIFY_SOCKET. It being documented is not the same thing as $NOTIFY_SOCKET
being documented

------
bwhmather
Option 1 is already provided. The sd_notify function is simply a convenience
wrapper for sending messages on a socket specified by the NOTIFY_SOCKET
environment variable.

See the notes in sd_notify(3) or [https://lists.debian.org/debian-
ctte/2013/12/msg00230.html](https://lists.debian.org/debian-
ctte/2013/12/msg00230.html) for a simple alternative implementation.
Admittedly could be better documented.

edit: point to notes section

~~~
mzs
MSG_NOSIGNAL is a portability PITA.

------
kamme
Well, pointing out what is wrong with systemd proves to be very easy for some
people, but fixing the issues pointed out or even start building something
different that doesn't have these flaws and still can innovate, is quite
another story. There is definitely a lot of hate towards systemd (ignore the
justified or not argument), but a complete lack of equally innovative
alternatives.

Imho this is the semi-religious 'vim vs emacs' debate all over again, except
this time it's not between equally good pieces of software but a 'systemd is
garbage' group against the rest...

~~~
mansr
It's "systemd is garbage" vs "everything else is garbage".

------
oconnore
> forking - assumes the original process invoked to start the daemon will exit
> once the daemon is successfully initialized, and not earlier. Requires a pid
> file and is subject to all the traditional flaws of pid files (but systemd
> can mitigate them somewhat by being the process that inherits orphans).

No, systemd uses cgroups to manage forked processes (with the option of pid
files).

I'm not sure why I should seriously consider a critique of systemd by someone
who doesn't understand how systemd works.

~~~
Alupis
I think the fact that the article title has a capitalized "S" in "systemd"
speaks for itself -- ie. the author doesn't know much about systemd nor has
followed systemd development.

~~~
pgeorgi
The other systemd mentions in the article are spelled correctly.

There are some capitalization styles that always start sentences with caps. It
used to annoy me with "Coreboot" (instead of "coreboot"), too - but it really
isn't a big deal.

------
loftsy
I thought that a forking init script was supposed to wait for the service to
be active before exiting. Otherwise you run "service apache2 start" and apache
has not yet started after the command terminates.

This is the same requirement systemd has for the "forking" type daemon.

~~~
asdfaoeu
This, just because OP can't figure out how to forking doesn't somehow mean
systemd screwed up.

Either the socket activation or notify approach don't need linking against a
systemd library either they can just be done in < 20 lines of code.

~~~
loftsy
Note the irony of the situation. Writing an init.d script is actually really
hard. A post attacking Systemd is actually a pretty good argument for using
it.

~~~
throwaway7767
The common argument that systemd makes init jobs unportable sounds quite funny
to me. I've used a lot of *NIX systems and init.d jobs are anything but
portable, unless you fill them with OS-specific hacks.

~~~
vertex-four
The issue isn't that systemd makes init configurations unportable, it's that
it makes programs unportable by tying them to systemd. What do we do 5 years
down the line when we realise systemd was a bad idea and want to replace it
with something else?

~~~
Tuna-Fish
We have that something else, or maybe another component of the system
implement the systemd notify api?

~~~
vertex-four
systemd has a vast number of APIs, especially inter-component ones, which are
unstable and undocumented, meaning you'd have to replace the entire thing
wholesale if you didn't want certain parts of it (especially its PID 0).

The thread we're on is talking about a _public_ API that's not documented
sufficiently for alternative implementations to be created without reading its
source code.

------
mjg59
"They're all wrong", followed by listing three mechanisms provided by systemd
that get this right (socket activation, the dbus method, the notify method).
The underlying problem is that there's no solution that's portable across init
systems. That's not systemd's problem - ever other init system has also failed
in this respect.

~~~
rlpb
> The underlying problem is that there's no solution that's portable across
> init systems.

He describes one that would be portable. Even upstart's SIGSTOP hack is
portable across any init system that chooses to implement it; no linking to
any init-system-specific library required.

~~~
mjg59
His option 1 is less featureful than the protocol provided by systemd, and is
also not implemented by any other init daemon. His option 2, well. No. Doing
it reliably means task-specific knowledge, which means adding the same kind of
complexity that init scripts are currently full of. Maintaining this knowledge
in the daemon is absolutely the correct thing to do. It would obviously be
preferable to have one mechanism that works across all init daemons, but since
there isn't one we're stuck with the current situation.

systemd's implementation is exactly as portable as upstart's hack - any OS can
implement it. The relevant code is under a liberal license.

~~~
felixgallo
the original poster showed two ways to achieve a better result with less
coupling. Given that systemd is already pushing a myriad of other mechanisms
not implemented by any other init daemon, one has to wonder why you are even
trying to dismiss the argument rather than engaging with it. Is it that you
think strong coupling is good in systems?

~~~
mjg59
No. Right now if anyone implemented option 1 in an init daemon, applications
using it would be coupled to that init daemon. So it doesn't reduce coupling.
It's also worse than sd_notify() from a technical perspective - there's no
mechanism for passing metadata such as the PID to track, or information about
the failure, or watchdog support and so on.

Option 2 is just shit.

I'd prefer a cross-init mechanism for this. But there isn't one. What should
systemd do? Just not implement anything until SMF and launchd developers agree
to add support?

~~~
felixgallo
I think we can all agree that any mechanism is going to involve coupling; the
question is, how much, and what limits does that impose?

The proposed 'use unix pipes' architecture proposed by the original author
('option 1') doesn't bind a daemon to a particular operating system or init
system, because it uses a kernel feature common to all unix variants. And of
course it itself is a mechanism for passing metadata, so your argument doesn't
make sense.

Using a socket would also be fine, and if systemd chose to expose and document
that socket API directly, rather than hiding it behind a C shim, that would be
tolerable. But since systemd's modus operandi so far has been to attempt to
become tightly coupled to every userland component, I'm not holding my breath.

~~~
mjg59
The underlying NOTIFY_SOCKET implementation is defined as a supported
interface
([http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...](http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/)),
and is documented
([http://www.freedesktop.org/software/systemd/man/sd_notify.ht...](http://www.freedesktop.org/software/systemd/man/sd_notify.html),
see the Notes section).

~~~
felixgallo
That is not documentation, that is incomplete[1] notes in a man page of a
library call. That said, that's getting pretty close to a correctly uncoupled
implementation.

[1]
[https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3](https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3)

~~~
mjg59
The notes define that a socket name starting with @ is a Linux abstract
namespace socket, so I don't see where "incomplete" comes from. You can
quibble over whether the documentation meets your preferred style (and I'll
admit it certainly is odd to reference the underlying implementation in the
notes for the wrapper rather than the other way around), but it's a page of
text, shipped with the code, that tells you everything you need to reimplement
it.

~~~
felixgallo
The link I included in my comment shows that the behavior is not actually what
is stated in the notes. Do you have any documentation that describes the
complete behavior?

~~~
mjg59
That's how Linux abstract sockets work. They're documented in unix(7).

~~~
felixgallo
oh man, that's a ridiculously grotesque hack. Huh! Thanks! You learn something
new every day.

That said, now I don't understand why one would use these things instead of
something less openly hacky, like normal portable sockets, which have all
sorts of advantages. And I can't find a reason why these were implemented in
such a weird and nonportable way. From all I can piece together from the web,
it looks like these were implemented by the freedesktop guys for that hacky
desktop bus thing, is that right?

Well that's an aside; in any case, having discovered this unnecessary coupling
to a hacky linux-only feature, I would go back to the OP's idea of using
standard unix IPC, which for the purpose appears to be more than enough to do
the job but doesn't bring baggage. Any idea why that would be a bad thing?

~~~
mjg59
Abstract sockets were added to Linux waaaaaaaaaaaay before dbus existed - they
were already there in 2.4.0, which is as far back as the history I have goes.
You really can't blame the Freedesktop people for them. If your init daemon
doesn't run on Linux there's no reason to care about supporting them, either.
Write a library that implements sd_notify(), and just leave that bit out.

------
awalton
> However, none of the above choices actually make it possible to do this with
> a daemon that was not written specifically to interact with systemd!

Et voila, you found your answer. Target systemd, problem solved.

~~~
zdw
... and give up the ability to easily run on any non-systemd system, like BSD,
Solaris, OSX, older/embedded Linux distros, and basically any other Unix. Oh,
and it's GPL'ed so most of those systems won't use it.

Requiring systemd is like saying every daemon program needs a GUI.

~~~
epochwolf
You can't put systemd code behind a compile flag?

------
ausjke
Rob had an excellent article about systemd
[http://www.landley.net/notes.html#23-04-2014](http://www.landley.net/notes.html#23-04-2014)

Is there a way, or any way to somehow stop systemd which is from Redhat? I'm
very worried as I don't want to be _forced_ to use it on my embedded projects.
Redhat does not know as much embedded system as their big gun server systems.

~~~
bkor
If you have issues with systemd in an embedded project, raise it so that
systemd can be improved. Be a bit open in your thoughts. Note that systemd is
used on various embedded systems already.

~~~
ausjke
As stated in Rob's article, which I agree 100%, there is no point to 'improve'
it, as it's something on the wrong track for me. IMHO, it's a disaster.

------
sgtnasty
Here we go again...

------
jwildeboer
Dear pmarin, any specific reason why you bring up this critique from February
now? Did something dramatic happen that makes this rant relevant again? Or are
you just trolling? ;-)

------
exDM69
To the OP: why don't you do something about it?

Judging by the comments to this post (and the links that the comments refer
to), the author hasn't got all their facts straight. Also it seems like the
author has some kind of personal hatred towards systemd, which doesn't seem to
be based on real technical issues and has been writing similar vitriolic blog
posts in the past.

This anti-systemd bashing is a complete waste of time. Don't like systemd?
Don't use it. Do you think there is something wrong with it? Go fix it. Do you
think it's done all wrong from the bottom up? Write a better replacement. But
please, stop writing crap like this.

~~~
cthalupa
>This anti-systemd bashing is a complete waste of time. Don't like systemd?
Don't use it.

This is increasingly becoming a completely unviable option. As more and more
distros adopt it as the standard, and more and more software becomes dependent
on it and it's various parts, it becomes increasingly difficult to just not
use systemd. Particularly those of us in the enterprise world, where we have a
limited number of distros that are acceptable for server related work, most of
which are now set on systemd being their init system moving forward.

>Do you think there is something wrong with it? Go fix it.

Not everyone that uses Linux is a developer. Not every developer that uses
Linux works in the realm of knowledge related to init systems. The group
managing systemd is also known to be more than a bit vitriolic and opinionated
- what you believe is wrong might be something they thing is right. This isn't
necessarily a bad thing - but it does mean that the idea of just fixing it is
impractical, even if you have the necessary skills to correct what you think
is broken.

>Do you think it's done all wrong from the bottom up? Write a better
replacement.

A fair amount of the people that think it's wrong from the bottom up think
there are already perfectly acceptable replacements.

>But please, stop writing crap like this.

I haven't gone over the article in depth, but... why? Why are you so upset
that people are using the avenue they have available to make their opinion
known? The Linux community has far outgrown the days where it was a developer
only playground, so your proposed ideas of just write some code to solve
everything is ridiculous.

Personally, I'm past caring on the systemd issue - I've long since replaced
all of my servers with BSD or Illumos based distros, so I don't have a horse
in this race anymore. I just don't understand the visceral reaction of some
people in the Linux community to go "STOP SHARING YOUR OPINIONS, IF YOU THINK
SOMETHING IS WRONG JUST MAKE IT BETTER"

~~~
josteink
_This is increasingly becoming a completely unviable option. As more and more
distros adopt it as the standard_

Distros has always had standards and this has never been an issue before.

 _more and more software becomes dependent on it and it 's various parts_

This is something completely different and unrelated from what distros decide
to do.

For instance, while I really like systemd as a Linux-specific init-system, I
cannot for the love of all that is good architecture understand why Gnome, a
desktop-environment running on top of X, _maybe_ running on top of Linux,
should make it self dependent on a Linux-specific component like systemd.

In cases like that you should not hate systemd, but on the guilty party
introducing the bad dependency. This is clearly not systemd's fault.

~~~
cthalupa
>Distros has always had standards and this has never been an issue before.

While distros adopting standards has been polarizing in the past, I think this
is the most debated issue in the past decade or two. There's been some
quibbles over things, and of course there's the vi vs emacs holy wars, etc,
but I can't think of a single time where something so integral to the
distribution has been such a matter of controversy across the community.

>In cases like that you should not hate systemd, but on the guilty party
introducing the bad dependency. This is clearly not systemd's fault.

Oh, I'm not blaming systemd for this (Though it's not surprising Gnome has
done this - the Freedesktop.org group is fairly incestuous when it comes to
this sort of thing), I'm just saying it's pretty easy to say "Don't use
systemd if you don't like it then!", but increasingly more difficult to
actually do it.

It's not like vi vs emacs or nginx vs apache where you can quite easily just
use the one you want.

