Drop support for /usr/sbin/halt.local

[mbiebl]

/usr/sbin/halt.local is a Fedora/Red Hat anachronism from pre-systemd
times.

[poettering]

hmm, i am pretty sure that if we drop that we also should drop rc.local support...

are you sure ups software got updated to not use this anymore? i doubt so?

[mbiebl]

/etc/rc.local seems to be something used/supported on basically every distro and in more wide spread use still, which is why I think there is still some value keeping it.
/usr/sbin/halt.local on the other hand seems to be a Fedoraism. E.g the Debian/Ubuntu family of distros never supported a mechanism like that and while researching this, I only found references of /usr/sbin/halt.local for Fedora/Red Hat based systems.

[mbiebl]

Regarding UPS software: If it really required support for /usr/sbin/halt.local, then that software would be broken on any non-Fedora distro.
We do provide a much better mechanism via systemd-shutdown and looking at the UPS software shipped in Debian, they do seem to use that interface. E.g.

nut-server: /lib/systemd/system-shutdown/nutshutdown
apcupsd: /lib/systemd/system-shutdown/apcupsd_shutdown

[keszybz]

Yeah, let's do this. I'm pretty sure nobody will care, and if they do, it's trivial to revert this commit in specific distros that need it.

Ref: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553

https://forums.opensuse.org/showthread.php/500034-12-3-halt-local-does-not-run-at-shutdown
It seems opensuse has/had /etc/init.d/halt.local. Not sure if this is using this mechanism, or is just a normal sysvinit script.

Edit: opensuse indeed uses --with-rc-local-script-path-stop=/etc/init.d/halt.local. So let's wait a bit for feedback if they still care.

[mbiebl]

@keszybz thanks for the pointer regarding (open)SUSE. Let's wait for feedback from their side.

An alternative I had considered was changing --with-rc-local-script-path-stop= to treat an empty path as "disable that feature and don't install halt-local.service`. Then again, investing more time into that is probably not a good idea when we can just drop that feature.

[mbiebl]

@keszybz what I don't quite understand: If openSUSE installs halt.local as /etc/init.d/halt.local, wouldn't that be covered by systemd-sysv-generator anyway?

[keszybz]

I think this allows them not to have to enable it (in the sysvinit sense), but it works "automagically". But yeah, it seems rather confusing to place it there.

[Conan-Kudo]

As one of the Mageia systemd maintainers, I'd actually rather see all of this killed at once (rc.local and halt.local) rather than only the halt.local stuff. Or at least, split it out like it was done for the initctl stuff to a separate project that can be packaged separately.

[mbiebl]

Dropping halt.local support seemed less controversial to me.
If there is an overall consensus to drop rc.local as well then I'm fine with that.

Within Debian/Ubuntu, we never supported halt.local and no longer install a /etc/rc.local on fresh installations. We do have existing/upgraded systems though, and I would prefer not to break those.
I guess what we could do is to ship a rc-local.service in /usr/share/systemd/ and copy that to /etc/systemd/system on upgrades, if a /etc/rc.local is found.
@xnox, @fsateler, @martinpitt wdyt?

[Conan-Kudo]

@mbiebl Couldn't the rc-local generator just be split out into its own project under the systemd org, especially now that system generators are now a thing in systemd?

[keszybz]

Query in Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LI77ZFZIXORRGKFG2OBJXTUQBFFLMZIF/
(there are no users apparently).

@fbuihuu comments from opensuse side?

Couldn't the rc-local generator just be split out into its own project under the systemd org, especially now that system generators are now a thing in systemd?

It's not worth the trouble. If we drop it, let's just drop it.

[mbiebl]

@mbiebl Couldn't the rc-local generator just be split out into its own project under the systemd org, especially now that system generators are now a thing in systemd?

Then we wouldn't gain anything. It would just mean more work for us to package a separate binary.

[Conan-Kudo]

I've just now sent an equivalent email to the Mageia dev mailing list: https://ml.mageia.org/l/arc/dev/2019-05/msg00578.html

[mbiebl]

Within Debian/Ubuntu, we never supported halt.local and no longer install a /etc/rc.local on fresh installations. We do have existing/upgraded systems though, and I would prefer not to break those.
I guess what we could do is to ship a rc-local.service in /usr/share/systemd/ and copy that to /etc/systemd/system on upgrades, if a /etc/rc.local is found.
@xnox, @fsateler, @martinpitt wdyt?

Hm, alternatively we might just ship such an rc-local.service in /lib/systemd/system and do a one-time migration during upgrades (enable the service if /etc/rc.local exists and is executable).

[mbiebl]

I've just now sent an equivalent email to the Mageia dev mailing list: https://ml.mageia.org/l/arc/dev/2019-05/msg00578.html

The responses so far are what I expected: halt.local is something apparently no-one cares about and rc.local is something users might be unhappy about if we drop support for it.

[fbuihuu]

Edit: opensuse indeed uses --with-rc-local-script-path-stop=/etc/init.d/halt.local. So let's wait a bit for feedback if they still care.

Well those legacy scripts have been supported for years so the only feedback I can provide is that we must at least observe a period of deprecation. If upstream decides to drop the support upstream now then downstreams will have to provide backward compatibilities in theory.

So to avoid duplicating this work, deprecating those scripts (if we decide to do so) upstream and warn loudly users who use these scripts (especially halt.local) would be simpler IMHO.

BTW SUSE started deprecating them 3 years ago, see openSUSE/aaa_base@d1e4cb0. But I guess no actual users have noticed.

[keszybz]

It seems rc.local has users, but nobody cares about halt.local. In addition, rc.local is something of a standard, but halt.local is supported by only a subset of distros and slightly different in each one. It seems reasonable to merge this patch as-is, i.e. drop halt.local but keep rc.local for now.

We should also work on some documentation how to provide a quick service using systemctl edit and systemctl add-wants.

[frispete]

In the openSUSE factory ML, we got a note for this, accompanied with a hint to look into man systemd-shutdown(8) for a replacement. Guess what, I did, and now I know about the systemd shutdown logic, but still missing an obvious way to replace my /etc/init.d/halt.local script easily.

Mind briefly describing a replacement procedure here?

Thanks in advance.

[coling]

In the openSUSE factory ML, we got a note for this, accompanied with a hint to look into man systemd-shutdown(8) for a replacement. Guess what, I did, and now I know about the systemd shutdown logic, but still missing an obvious way to replace my /etc/init.d/halt.local script easily.

Mind briefly describing a replacement procedure here?

From that man page:

Immediately before executing the actual system halt/poweroff/reboot/kexec systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/ and pass one arguments to them: either "halt", "poweroff", "reboot" or "kexec", depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished.

So I think all you'd need to do is move your /etc/init.d/halt.local script to /usr/lib/systemd/system-shutdown/ and ensure it's argument parsing works according to the above description (if needed) and you should be fine.

[frispete]

Sorry for my blindness. One should never deal with such things while nursing a cold.