6 ms·

Systemd has 6 service startup notification types, and they're all wrong

48 points by pmarin 12y ago

kamme 12y ago
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 12y ago
  It's "systemd is garbage" vs "everything else is garbage".
exDM69 12y ago
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.
- makomk 12y ago
  A lot of the comments are actually wrong though. For example, someone accused the author of lying for saying "There is no documented, stable way for a daemon to use either of these options without linking to D-Bus's library and/or systemd's library" - and as evidence, pointed to systemd's "stable interface" for startup notification, which is a C API that requires daemons to link against a systemd-provided library. Their own source confirms the blog poster's claims, and yet they accuse him of lying and having no scruples whatsoever for making them. Edit: Interestingly, it looks like one of the other Wiki pages[1] does specificially call out the underlying $NOTIFY_SOCKET protocol as a stable interface. (Then points to an authoritive chart that doesn't, presumably because the implementation details of the other sd-daemon.h APIs aren't stable despite being documented in the same way?) [1] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...
  - asdfaoeu 12y ago
    Include this. http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-daemon/sd-daemon.c http://cgit.freedesktop.org/systemd/systemd/tree/src/libsyst...
    - mzs 12y ago
      ... systemd is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License... What if I can't?
  - bkor 12y ago
    The code for that is stable, it is just that the recommended way is using that library. When people asked, the code was provided to do this without linking. Just that linking is way more reliable. The comment should've stated something like "the way to do this is not documented". The way it is currently worded implies something totally different.
    - rlpb 12y ago
      > Just that linking is way more reliable. Why? Is not linking somehow unreliable? You can't have it both ways. Either it is stable, or it is not.
      - bkor 12y ago
        Don't put words into my mouth to win an argument. I'm saying that linking to a function is more reliable than copy/pasting that stuff into your program. If you want to argue that copy/pasting is totally fine, go ahead. I'm sure enough people will respond to that :-P
- baldfat 12y ago
  I believe the hatred for systemd has a few sources. 1) The first round was. This guy wrote pulseaudio! 2) This goes against the Unix philosophy 3) Systemd is taking over everything. Why replace init?
  - josteink 12y ago
    2) This goes against the Unix philosophy Just like ZFS, Btrfs and SANs and cloud-systems in general. And they are really suffering in popularity for these terrible violations, eh? After having fooled around with it, my only complaint as far as systemd goes is software needlessly making it a dependency. systemd itself is just fine.
    - pgeorgi 12y ago
      I remember ZFS being lambasted for its "layering violations" a lot. Also SMF for its binary formats. Now there's btrfs with the same type of "layering violations" and systemd ('s ecosystem) using binary formats. What's good for the goose, ...
  - matthewmacleod 12y ago
    1) The first round was. This guy wrote pulse audio! No argument there. 2) This goes against the Unix philosophy Not a valid argument, nor true. 3) Systemd is taking over everything. Why replace init? We all know what the problems with traditional init systems are, and they have to be replaced. Systemd currently appears to be the favourite option.
- cthalupa 12y ago
  >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"
  - bkor 12y ago
    > 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. The author has the ability to write code. So his suggestion is relevant. But instead of writing code, he's writing highly opinionated "articles" full of claims that distort what is really going on. Opinions stated as facts, suggesting things by the way things are written, etc. That'll just get you nowhere. Constructive but harsh articles are good. This? No
- 4ad 12y ago
  > why don't you do something about it? You've picked the wrong guy here. Rich Felker has done extremely valuable and useful work[1] for the Linux ecosystem. You know, unlike Lennart Poettering who brought us pain through PulseAudio and systemd. > 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. His posts are purely technical and of extremely high quality, and if you can't see that, then this forum has failed. [1] http://www.musl-libc.org/ http://www.musl-libc.org/
  - ausjke 12y ago
    Fully agree here
  - bkor 12y ago
    > His posts are purely technical and of extremely high quality Don't understand how you can claim this. The posts are highly emotional, very suggestive and a lot of things are plain wrong. > if you can't see that, then this forum has failed. Whatever. That's not an argument.
bwhmather 12y ago
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 12y ago
  MSG_NOSIGNAL is a portability PITA.
loftsy 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
        We have that something else, or maybe another component of the system implement the systemd notify api?
zimbatm 12y ago
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/libsystemd/sd-daemon/sd-daemon.c#n381 http://cgit.freedesktop.org/systemd/systemd/tree/src/libsyst... 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.
- ieG9ique 12y ago
  this seems to be a common misunderstanding how apis and protocols work: you cannot just copy-past the internal implementation because that may change, the only thing that is stable is the public documented interface in this case the public and documented interface is sd_notify and it is only available as part of a huge library that every service has to link to their binary it would be nice if systemd authors werent completely ignorant about sensible interface design between software components now that ppl started to depend on random internal behaviour of systemd it is no longer possible to reimplement it in a sensible way: nobody knows which systemd quirk your ruby project depends on
  - asdfaoeu 12y ago
    > this seems to be a common misunderstanding how apis and protocols work: you cannot just copy-past the internal implementation because that may change, the only thing that is stable is the public documented interface It isn't an internal interface. http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
- cthalupa 12y ago
  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.
ausjke 12y ago
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 12y ago
  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 12y ago
    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.
- pling 12y ago
  Not joking but we're moving our Linux-based stuff to FreeBSD (mainly operations stuff, mail, dev systems, cache and monitoring). We've done a lot of recent work and FreeBSD scales down better to smaller systems. Systemd isn't the only reason but it's a big motivator as we're really not interested in factionism and politics, just reliability and longevity.
awalton 12y ago
> 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 12y ago
  ... 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 12y ago
    You can't put systemd code behind a compile flag?
  - awalton 12y ago
    Who said anything about requiring systemd? All you have to do is handle it when it's there. It's no different than any other portability concern that has ever existed on any platform ever.
oconnore 12y ago
> 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.
- makomk 12y ago
  It uses cgroups to contain forking daemons somewhat and detect certain kinds of failure, but it doesn't use them to work out when the daemon's finished starting and is ready, which is what the blog post mainly seems to be about.
- Alupis 12y ago
  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 12y ago
    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.
mjg59 12y ago
"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 12y ago
  > 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 12y ago
    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 12y ago
      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 12y ago
        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?
jwildeboer 12y ago
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? ;-)
sgtnasty 12y ago
Here we go again...

48 points by pmarin 12y ago

kamme 12y ago

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 12y ago
It's "systemd is garbage" vs "everything else is garbage".

exDM69 12y ago

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.

makomk 12y ago
A lot of the comments are actually wrong though. For example, someone accused the author of lying for saying "There is no documented, stable way for a daemon to use either of these options without linking to D-Bus's library and/or systemd's library" - and as evidence, pointed to systemd's "stable interface" for startup notification, which is a C API that requires daemons to link against a systemd-provided library. Their own source confirms the blog poster's claims, and yet they accuse him of lying and having no scruples whatsoever for making them. Edit: Interestingly, it looks like one of the other Wiki pages[1] does specificially call out the underlying $NOTIFY_SOCKET protocol as a stable interface. (Then points to an authoritive chart that doesn't, presumably because the implementation details of the other sd-daemon.h APIs aren't stable despite being documented in the same way?) [1] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...
- asdfaoeu 12y ago
  Include this. http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-daemon/sd-daemon.c http://cgit.freedesktop.org/systemd/systemd/tree/src/libsyst...
  - mzs 12y ago
    ... systemd is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License... What if I can't?
- bkor 12y ago
  The code for that is stable, it is just that the recommended way is using that library. When people asked, the code was provided to do this without linking. Just that linking is way more reliable. The comment should've stated something like "the way to do this is not documented". The way it is currently worded implies something totally different.
  - rlpb 12y ago
    > Just that linking is way more reliable. Why? Is not linking somehow unreliable? You can't have it both ways. Either it is stable, or it is not.
    - bkor 12y ago
      Don't put words into my mouth to win an argument. I'm saying that linking to a function is more reliable than copy/pasting that stuff into your program. If you want to argue that copy/pasting is totally fine, go ahead. I'm sure enough people will respond to that :-P
baldfat 12y ago
I believe the hatred for systemd has a few sources. 1) The first round was. This guy wrote pulseaudio! 2) This goes against the Unix philosophy 3) Systemd is taking over everything. Why replace init?
- josteink 12y ago
  2) This goes against the Unix philosophy Just like ZFS, Btrfs and SANs and cloud-systems in general. And they are really suffering in popularity for these terrible violations, eh? After having fooled around with it, my only complaint as far as systemd goes is software needlessly making it a dependency. systemd itself is just fine.
  - pgeorgi 12y ago
    I remember ZFS being lambasted for its "layering violations" a lot. Also SMF for its binary formats. Now there's btrfs with the same type of "layering violations" and systemd ('s ecosystem) using binary formats. What's good for the goose, ...
- matthewmacleod 12y ago
  1) The first round was. This guy wrote pulse audio! No argument there. 2) This goes against the Unix philosophy Not a valid argument, nor true. 3) Systemd is taking over everything. Why replace init? We all know what the problems with traditional init systems are, and they have to be replaced. Systemd currently appears to be the favourite option.
cthalupa 12y ago
>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"
- bkor 12y ago
  > 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. The author has the ability to write code. So his suggestion is relevant. But instead of writing code, he's writing highly opinionated "articles" full of claims that distort what is really going on. Opinions stated as facts, suggesting things by the way things are written, etc. That'll just get you nowhere. Constructive but harsh articles are good. This? No
4ad 12y ago
> why don't you do something about it? You've picked the wrong guy here. Rich Felker has done extremely valuable and useful work[1] for the Linux ecosystem. You know, unlike Lennart Poettering who brought us pain through PulseAudio and systemd. > 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. His posts are purely technical and of extremely high quality, and if you can't see that, then this forum has failed. [1] http://www.musl-libc.org/ http://www.musl-libc.org/
- ausjke 12y ago
  Fully agree here
- bkor 12y ago
  > His posts are purely technical and of extremely high quality Don't understand how you can claim this. The posts are highly emotional, very suggestive and a lot of things are plain wrong. > if you can't see that, then this forum has failed. Whatever. That's not an argument.

bwhmather 12y ago

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 12y ago
MSG_NOSIGNAL is a portability PITA.

loftsy 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        We have that something else, or maybe another component of the system implement the systemd notify api?

zimbatm 12y ago

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/libsystemd/sd-daemon/sd-daemon.c#n381 http://cgit.freedesktop.org/systemd/systemd/tree/src/libsyst... 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.

ieG9ique 12y ago
this seems to be a common misunderstanding how apis and protocols work: you cannot just copy-past the internal implementation because that may change, the only thing that is stable is the public documented interface in this case the public and documented interface is sd_notify and it is only available as part of a huge library that every service has to link to their binary it would be nice if systemd authors werent completely ignorant about sensible interface design between software components now that ppl started to depend on random internal behaviour of systemd it is no longer possible to reimplement it in a sensible way: nobody knows which systemd quirk your ruby project depends on
- asdfaoeu 12y ago
  > this seems to be a common misunderstanding how apis and protocols work: you cannot just copy-past the internal implementation because that may change, the only thing that is stable is the public documented interface It isn't an internal interface. http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
cthalupa 12y ago
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.

ausjke 12y ago

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 12y ago
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 12y ago
  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.
pling 12y ago
Not joking but we're moving our Linux-based stuff to FreeBSD (mainly operations stuff, mail, dev systems, cache and monitoring). We've done a lot of recent work and FreeBSD scales down better to smaller systems. Systemd isn't the only reason but it's a big motivator as we're really not interested in factionism and politics, just reliability and longevity.

awalton 12y ago

> 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 12y ago
... 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 12y ago
  You can't put systemd code behind a compile flag?
- awalton 12y ago
  Who said anything about requiring systemd? All you have to do is handle it when it's there. It's no different than any other portability concern that has ever existed on any platform ever.

oconnore 12y ago

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

makomk 12y ago
It uses cgroups to contain forking daemons somewhat and detect certain kinds of failure, but it doesn't use them to work out when the daemon's finished starting and is ready, which is what the blog post mainly seems to be about.
Alupis 12y ago
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 12y ago
  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.

mjg59 12y ago

"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 12y ago
> 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 12y ago
  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 12y ago
    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 12y ago
      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?

jwildeboer 12y ago

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? ;-)

sgtnasty 12y ago

Here we go again...