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.