/etc/halt.local has become /usr/sbin/halt.local

[Thomas M Steenholdt]

Ubuntu 15.10, amd64
systemd-225-1ubuntu9

/etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons.

1) This is not where it's supposed to be
2) Locally modified (non-dpkg managed) scripts under /usr is bad

I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me.

Please let me know if you need more info from me

/Thomas

[Marius Gedminas (mgedmin)]

This seems to've been misfiled against the 'transmission' package, which is a BitTorrent client and has nothing to do with system shutdown scripts.

[Thomas M Steenholdt (tmus)]

You're absolutely right - Changed to systemd

[Martin Pitt (pitti)]

This is indeed configurable with --with-rc-local-script-path-stop=. However, I want to make sure we actually point it to a sensible value. I can't find any reference to halt.local in Debian/Ubuntu. It seems neither sysvinit nor upstart ever supported that file, so I don't think there's any backwards compatibility issue here. http://www.linux-tutorial.info/modules.php?name=ManPage&sec=7&manpage=init.d talks about /etc/init.d/halt.local, but that looks SuSE specific.

Where did you actually see /etc/halt.local documented? Thanks!

[Thomas M Steenholdt (tmus)]

Hmmm I can't seem to find it documented anywhere, but last time I needed this to work was in the good old sysvinit days and it may have even been on a different distro. Sorry for not brushing thoroughly up on this, prior to filing this bug.

I have checked with CentOS 7 and it has the halt.local placed in /usr/sbin/halt.local as well

In any case, this is part of the rc-local type magic that systemd performs and with rc.local in /etc/rc.local, one could argue, that it makes sense for these scripts to be located together.

But more importantly, user-maintained stuff in /usr/sbin/ is just bad practice and we should not encourage people to do that.

/T

[Martin Pitt (pitti)]

Oh, I absolutely do agree that /usr/sbin/ is a really bad place. /usr/local or /etc/ are better indeed. I was just wondering about what precise path it should be, as I have never seen this documented or being used in a Debian context.

[Martin Pitt (pitti)]

So it seems we are not actually breaking any backwards compatibility here, so we could just use /etc/halt.local corresponding to /etc/rc.local.

[Martin Pitt (pitti)]

http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=944c47b

[Martin Pitt (pitti)]

After discussing with Michael Biebl we decided to drop this altogether: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=832bc79

[Thomas M Steenholdt (tmus)]

In that case we are missing documentation for the shutdown/halt procedure more than ever.
Very often halt.local is where we'd do stuff like powering off UPS outlets, to handle power-outage scenarios properly. It may not have been documented or placed ideally, but AFAIKT, it's actually always worked. Without the halt-local.service, we're missing that easy hook, as I see it.

The nut package for one, does not include a systemd unit that can do the exact same thing, and to my experience, figuring out exactly which depencencies to create for a new unit tile to accomplish the same without breaking something else, is really not that well documented, or just not very easy to find.

[Martin Pitt (pitti)]

Check out systemd-halt.service(8), this provides a hook directory for this kind of things.

[Martin Pitt (pitti)]

> it's actually always worked

Not that I can see in Debian/Ubuntu -- there is no trace of it in sysvinit or upstart..

[Michael Biebl (mbiebl)]

Before the introduction of systemd in Debian and Ubuntu, /etc/halt.local was not supported at all.
Neither sysvinit nor upstart executed that file/script. So I'm mildly suprised, when you say "it always worked".

We decided to not introduce support for this legacy, sysv specific service, which after a bit of research seems to be Redhat (/sbin/halt.local) and SuSE (/etc/init.d/halt.local) specific.

Adding /etc/halt.local to the mix would only confuse things.
It's much better to create a native service file with systemd, and it's much easier.

[Thomas M Steenholdt (tmus)]

Also all other distros, regardless of init system, appears to have this file somewhere. Bad solution IMHO

[Thomas M Steenholdt (tmus)]

Thowing user-managed executables in /lib/systemd/system-shutdown/ is not much better than editing /usr/sbin/halt.local. Is there an /etc or a /usr/local based version of this directory available somewhere, that will work out of the box, then that will work for me, i guess.. I'll try it out at least.

[Michael Biebl (mbiebl)]

Add a native service file and hook it up in the shutdown.target. That's the cleanest solution.

/etc/systemd/system/foo.service
[Unit]
Description=Run service on shutdown

[Service]
ExecStart=/bin/true

[Install]
WantedBy=shutdown.target

[Michael Biebl (mbiebl)]

Or make that
WantedBy=final.target, if you want to execute it during late shutdown.

See man systemd.special(7)

[Thomas M Steenholdt (tmus)]

Fair enough...

As mentioned earlier, this may be from a systemv time and perhaps from Red Hat, I'm not sure. I do know that /usr/sbin/halt.local works in both Wily and in debian 8 out of the box, the file is just located in dpkg-managed space, which makes no sense.

Look, I'm not actually arguing that we keep this particular file, but I think we need to keep the functionality. /lib/systemd/system-shutdown/ seems to provide that functionality, but again, this is in dpkg-managed territory. Is there a user managed folder that is handled the same?

If I need to create my own unit-file, I'd be happy to, but I've had a hard time figuring out the proper requiremends/dependencies/befores and afters that will make this the very last thing to run, just before the system prints "system halted". This is where the need for further documentation comes in (or perhaps I'm just too dense to find it)

If you can help point me to somewhere that will allow me to figure our the correct dependencies etc for a new unit-file, I'll be happy to let this go :-)

[Thomas M Steenholdt (tmus)]

Alright - Got your comments late, let me try that out

Are these targets documented somewhere, so it becomes clear exactly what is started when?

[Thomas M Steenholdt (tmus)]

systemd.special(7) explains what they are, but if I could somehow get the correlation between targets, that'd be cool

[Michael Biebl (mbiebl)]

man bootup(7)

[Michael Biebl (mbiebl)]

fwiw, halt-local.service was hooked up in final.target and contains the following:

[Unit]
Description=/usr/sbin/halt.local Compatibility
ConditionFileIsExecutable=/usr/sbin/halt.local
DefaultDependencies=no
After=shutdown.target
Before=final.target

To apply that to my /etc/systemd/system/foo.service example:

[Unit]
Description=Run service on shutdown
DefaultDependencies=no
After=shutdown.target
Before=final.target

[Service]
ExecStart=/bin/true

[Install]
WantedBy=final.target

Then run "systemctl enable foo.service" and you should be set.

[Thomas M Steenholdt (tmus)]

Thank you for your input. It's not working how I want it to right now, but I'm confident it can be done. I need to read up on systemd for this to work.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 228-5ubuntu1

---------------
systemd (228-5ubuntu1) xenial; urgency=medium

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - Simpler udev maintainer scripts (all platforms must support udev, no
      debconf).
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Chown the "systemd" controller of user scropes to the user. This makes
      unprivileged user LXC containers work under systemd, together with
      libpam-cgfs. (LP: #1346734)
    - Build using libseccomp on powerpc and ppc64el (See Debian #800818).

    Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README.
    - systemd.postinst: Migrate mountall specific fstab options to standard
      util-linux "nofail" option.
    - systemctl: Don't forward telinit u to upstart. This works around
      upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
      that changes to point to systemd during the upgrade. This avoids running
      systemd during a dist-upgrade. (LP: #1430479)
    - Break lvm (<< 2.02.133-1ubuntu1) and remove our dummy /etc/init.d/lvm2
      on upgrades, as it's shipped by lvm2 now.
    - Make udev break on mdadm << 3.3-2ubuntu3, as udev's init script dropped
      the "Provides: raid-mdadm".
    - Clean up /var/log/udev on upgrade (which is written under upstart, but
      not under systemd). (LP: #1537211)
    - Migrate existing s390x network configuration to new names. (LP: #1526808)

systemd (228-5) unstable; urgency=medium

  [ Martin Pitt ]
  * Drop systemd-vconsole-setup.service: It has never been installed/used in
    Debian and is not necessary for Ubuntu any more.
  * Drop halt-local.service. This has never been documented/used in Debian.
    (LP: #1532553)
  * debian/extra/initramfs-tools/scripts/init-bottom/udev: Prefer "nuke"
    again, it comes from klibc-utils. But fall back to "rm" if it does not
    exist.
  * systemd-timesyncd.service.d/disable-with-time-daemon.conf: Also don't run
    if /usr/sbin/VBoxService exists, as virtualbox-guest-utils already
    provides time synchronization with the host. (Closes: #812522)
  * Drop Michael Stapelberg from Uploaders:, he stopped maintenance long ago.
    Thanks Michael for your great work in the past!
  * Replace "sysv-rc" dependency with Conflicts: openrc, file-rc. The
    rationale from #739679 still applies, but with the moving of
    {invoke,update}-rc.d to init-system-helpers we don't actually need
    anything from sysv-rc any more other than the assumption that SysV init
    scripts are enabled in /etc/rc?.d/ for the SysV generator to work (and
    file-rc and openrc don't do that).
  * debian/tests/timedated: Verify /etc/localtim...