Skip to content
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

Conversation

fbuihuu
Copy link
Contributor

@fbuihuu fbuihuu commented Jun 3, 2016

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

…[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.
@poettering
Copy link
Member

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?

@poettering poettering added sysv-generator needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer labels Jun 3, 2016
@keszybz
Copy link
Member

keszybz commented Jun 4, 2016

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

@keszybz keszybz closed this Jun 4, 2016
@keszybz keszybz removed the needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer label Jun 4, 2016
@fmoreau
Copy link

fmoreau commented Jun 6, 2016

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

The same would happen for normal services, where the start and stop jobs would be coalesced into a nop.

@keszybz are you sure about that ? In my understanding, K symlinks are simply ignored for [1-5] runlevels by systemd.

@poettering
Copy link
Member

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

@fbuihuu
Copy link
Contributor Author

fbuihuu commented Jun 8, 2016

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

@poettering
Copy link
Member

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

@fbuihuu
Copy link
Contributor Author

fbuihuu commented Jun 8, 2016

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

@poettering
Copy link
Member

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

@fbuihuu
Copy link
Contributor Author

fbuihuu commented Jun 10, 2016

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.

@poettering
Copy link
Member

Yeah, I extended the wiki after this discussion, given that this was never written clearly there...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

4 participants