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.

Comments


Comments powered by Disqus