Why people hate #systemd

So yeah, I’ve been forced into using SystemD for just about everything now that the entire community has taken the koolaid.

I recently had a question where if a ConditionFileIsExecutable fails in the [Unit] section, the logs say that the service was started – but in fact the service won’t attempt to be started. No errors, no warnings, but a message of success. This seemed strange, so I jumped onto #systemd on Freenode and ended up with the following conversation:

17:37 -!- Irssi: Join to #systemd was synced in 5 secs
17:38 < CRCinAU> ok – so if the start of a service fails because ConditionFileIsExecutable fails, is it expected to be a silent failure?
17:38 < CRCinAU> ie nothing in the journal or logged to state why a service failed? just a “Started” then nothing further?
17:39 < grawity> CRCinAU: yeah, it’s supposed to be mostly silent
17:39 < grawity> unlike AssertFileIsExecutable=, by the way
17:39 < CRCinAU> logic behind that?
17:39 < grawity> its primary purpose is in filtering units which should or shouldn’t auto-start
17:40 < grawity> logging failures at default level would result in too much logspam on most systems
17:40 < CRCinAU> o_O
17:40 < grawity> e.g. there’s ssh-keygen.service with Condition= that at least one ssh_host_key is missing
17:41 < grawity> if you want things to be logged loudly, use Assert=
17:41 < CRCinAU> I don’t see a problem with that?
17:41 < grawity> with what
17:41 < CRCinAU> a message that a file doesn’t exist…..
17:41 < grawity> with users seeing “warning: ssh-keygen not started because EVERYTHING IS FINE” on every reboot?
17:42 < grawity> some programs install units with ConditionVirtualization=, which would either log warnings on every VM, or on every bare metal system
17:42 < grawity> if you want things to be logged loudly, use Assert=
17:42 < CRCinAU> wait……..
17:42 < CRCinAU> what the hell is systemd doing thinking about virtualisation?
17:43 < grawity> there are daemons which are only needed in VMs, or aren’t needed in VMs
17:43 < CRCinAU> urrrmmmm…….
17:43 < grawity> e.g. systemd’s own udev has no business running in a container
17:43 < CRCinAU> holy crap… so what you’re telling me is systemd is still hungry and needs to be fed more?
17:44 < michich> another example: vmtoolsd.service:ConditionVirtualization=vmware
17:44 < CRCinAU> I think I just died a little inside in that level of retardation.
17:45 < grawity> so by your own logic, a few minutes ago you were telling me systemd should be checking for your config files, instead of your own daemons doing that themselves?
17:46 < CRCinAU> no – the unit failed to start, and had no warning. if there was a problem and the unit failed, I’d expect to see something that says “blah.service failed because ConditionFileIsExecutable failed” or similar.
17:46 < CRCinAU> not just “Unit blah.service started”
17:46 < CRCinAU> when it fact it wasn’t
17:46 < CRCinAU> it *attempted* to start
17:46 < CRCinAU> but failed.
17:49 < CRCinAU> on another note, now I’m hearing that systemd is becoming virtualisation aware because users are too stupid to do “systemctl enable vmtoolsd.service” when they do a virtualised install?
17:49 -!- mode/#systemd [+b $a:CRCinAU] by evilgrawity
17:49 < CRCinAU> well, not even that… as I guess you’d have to install the VMWare tools in that situation to even have the service file in the first place – so it could even be part of the package install.
17:50 -!- #systemd Cannot send to channel
17:50 -!- CRCinAU was kicked from #systemd by evilgrawity [CRCinAU]

I’m kinda speechless now.


Skip to comment form

  1. So this started making rounds on the internets, which is quite unfortunate.

    Let me tell you something: you came to an IRC channel with a question, asked rather curtly, and you used as little politeness as possible.

    Despite that your question has been politely answered, along with an explanation about an existing convention of using ConditionXYZ for filtering and AssertXYZ for making noise.

    Instead of thanking for the information, you started behaving aggressively and using insults.

    Frankly, were I a chanop there, I’d kickban you immediately after using the “I think I just died a little” phrase.

    1. There is two schools of thought.

      School One is that SystemD is the system init that just has to be. It is the holy grail of system booting and its issues are all user error.

      School Two seems to think that a lot of the approaches taken by SystemD is broken and by its very complexity causes people and projects to incorrectly utilise systemd.

      I have big problems with the extra ‘features’ that have been added to SystemD that are now required because you can’t do something as simple as an IF statement – without starting it as a shell script – which in that case, what did we improve?

      The justification of “We have silent failures, and a failure that prints a log file” is a result of a broken design. It is the exact reason WHY initscripts became somewhat complex and not a simple 10 lines of config – and its because you have cases that just don’t fit into the SystemD model of the world – which means you need to use hacks.

      Couple this with no real feedback of what a system is doing – ie systemctl restart httpd – then did it launch ok? Well now I have to check the logs or do a process list to see if its running – as I no longer get an OK as feedback.

      While SystemD may be quite capable, I feel we’ve hidden so much from the systems administrator that we’ve actually made the job harder.

      As for the extensions to systemd to detect and operate differently under a VM environment so you can conditionally launch stuff based on the type of VM – this should NEVER be in a system startup stuff. If you’re not running vmware for instance, either 1) don’t install the service, or 2) fail with noise – not just silently ignore the start of a service.

    2. He was polite, concise, to the point, and did not attack or insult anyone. He asked valid, relevant questions trying to understand not only what is happening, but why. Even his comments expressing his opinion would not have violated the code of conduct in a school classroom, let alone any IRC channel I’ve ever participated in. If that earns a kickban in this community, I have to question whether any criticism from non-insiders is given any serious attention at all. Are all people who question the prevailing opinions in the systemd community similarly treated?

      Behavior like this chanop and the notorious hostility pervasive in the Linux kernel community – never mind my growing belief that from a technical standpoint systemd is actively hostile to actual working sysadmins – makes the BSD universe look better by the minute.

    • mark on October 2, 2017 at 3:12 pm
    • Reply

    Steve asked a simple question and the answer was typically systemd-arrogance by the core devs.

    There is no way to communicate with them if they do not give reasonable and logical answers to the problems that they have created in the first place.

    • PICCORO Lenz MckAY on December 30, 2017 at 3:16 pm
    • Reply

    systemd all realted now as we can see its a totally a crap

Leave a Reply

Your email address will not be published.