-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sysv-generator: fix dependencies generated for services in runlevels … #3430
sysv-generator: fix dependencies generated for services in runlevels … #3430
Conversation
…[06] If a SysV service is required to be started during shutdown (by installing a 'S' symlink in /etc/init.d/rc0.d/) then the service wasn't started at all because it was generated with "Conflict=shutdown.target". This patch fixes this case and also handles the weird case where both 'K' and 'S' symlinks are installed for the same service: the service won't be started nor stopped at all. IOW it will be ignored during the boot and shutdown process.
Humm? well, having a service that is in both K and S for the same runlevel is pretty borked, no? I don#t really grok what this is supposed to fix... I am strongly against supporting SysV services that run with DefaultDependencies=no. There's a reason why we removed support for early boot SysV services really, and I don't see why we should restore this through the backdoor... It's very well documented that we don#t support SysV services in early boot, as that isn#t portable anyway. Note that I actually removed the shutdown.target stuff entirely with #3392. I am pretty sure I should close this, unless I misunderstood something completely here. Can you make a better case for this? And especially one that doesn't involve DEfaultDependencies=no and working around obviously broken setups? |
Yeah, I don't think it makes much sense to add band-aids for sysv compatibility in early boot or late shutdown. Those areas are already frail, and way too complex, and we should be simplifying them. I'll close this now, because with #3392 merged, it would require significant reworking. (And actually not starting services which have both K and S configured for the same runlevel appears correct. The same would happen for normal services, where the start and stop jobs would be coalesced into a nop.) |
I missed the change done by #3392. @poettering however now that the support of the shutdown target is gone, I'm not sure how /etc/init.d/rc[06]/Sxxfoo symlinks are supposed to work... In my understanding such symlinks are supposed to start services when the system is shut down. And the patch fixed this case since the old cold didn't start those services at all (regardless there's a corresponding K symlink or not).
@keszybz are you sure about that ? In my understanding, K symlinks are simply ignored for [1-5] runlevels by systemd. |
@fmoreau we don't read the runlevel 0 or 6 data at all anymore in sysv-generator. Neither S nor K links have any effect in them. (And for runlevels 1-5 only S links have an effect now). |
@poettering well it seems that the support for rc[06] was dropped by accident since we switched to the sysv-generator (because that part was broken). Or did I miss its deprecation/removal notification ? (cannot find any traces of it in README nor in NEWS). And my patch attempted to fix this (and also have a more expected behavior for the borked case where K and S symlinks were defined). |
@fbuihuu we never really supported that. As mentioned, K links are unnecessary for shutdown, as we stop everything anyway. And the way to run something at shutdown is to start it first at startup, and use its ExecStop=. Or to say this differently: only very special late shutdown services are started at shutdown. Things like "systemd-reboot.service", but that's it. But since we don't permit late shutdown SysV services this is really out of scope... |
@poettering S links were supported before the sysv-generator was introduced. That is a symlink such as /etc/init.d/rc0.d/Sxxfoo did start a service when the system was shut down. |
@fbuihuu yeah, a long time ago we supported debian-style early-boot sysv runlevels too, but we don't anymore. SysV is only supported for normal runtime services really. |
I'm talking about the rc[06] runlevels, not the early boot ones. It looks like now it's officially stated : https://secure.freedesktop.org/cgit/www/commit/Software/systemd/Incompatibilities.mdwn?id=bb21198a5723caa104f90ae36e4a383848adbc3b , but this change was quite recent ;) Anyway we'll take care of this downstream now. |
Yeah, I extended the wiki after this discussion, given that this was never written clearly there... |
…[06]
If a SysV service is required to be started during shutdown (by
installing a 'S' symlink in /etc/init.d/rc0.d/) then the service
wasn't started at all because it was generated with
"Conflict=shutdown.target".
This patch fixes this case and also handles the weird case where both
'K' and 'S' symlinks are installed for the same service: the service
won't be started nor stopped at all. IOW it will be ignored during the
boot and shutdown process.