I have the following systemd unit:
I want to make sure this runs before all other shutdown services. How do I do that?

Hi!

Something like this might do the trick:
Try it out and see if it works on your system.

Best regards,
HMW

The key problem is "before all other shutdown services". Unfortunately systemd doesn't make that easy.

Using the "Before=shutdown.target reboot.target halt.target" doesn't get it run BEFORE any of the other tasks that also have the same "Before" specifications.

They all run in parallel.

Good point!

Unfortunately - this is one of the problems caused by systemd. The only way to force it is to first get a COMPLETE graph of the tasks being processed for shutdown. In the "old days" it was called a PERT chart (https://en.wikipedia.org/wiki/Progra...view_technique), but the problems with it was that it is very difficult (and time consuming) to get right, which was why the technique didn't scale (and went out of fashion for large projects). The more complex the network, the longer it takes to add ONE new node.

This was also why it took almost two years before Fedora had a (barely) working form of systemd boot. Originally, Fedora 14 was supposed to be systemd based (it didn't work), it was released with Fedora 15 (with LOTS of boot and shutdown problems), Fedora 16 mostly worked (still had shutdown hangs), but wouldn't work properly with a complex network at boot (multiple interfaces and virtual machines - Network Manager was goobered until "NetworkManager-wait-online" service was added). I skipped 17, 18, 19 (a number of boot/shutdown problems, but it would finally work for simple environments). Even now, there are occasional issues with shutdown (sometimes without logs... and though I haven't had shutdown hang, it can happen).

Adding a new node to startup/shutdown is not necessarily easy unless it doesn't depend on anything, and then, you have to know EVERYTHING it depends on, and everything that depends on it. In addition, it sometimes requires additional nodes (such as having any dependencies wait until after a possibly lengthy initialization).

The primary advantage the SysV init had over the BSD init was flexibility (BSD now has the equivalent). The advantage SysV init has over systemd is reliability, and ease of adding/removing modules. You can be sure of when things happen, and can relatively easily fix problems.

Yabbut ...
No-one want to wait anymore. How many "boot takes too long" threads do we see. Hence the parallelism drive - Canonical tried it too.

It's a bit like the "if you use eval you're doing it wrong" argument. If you want to single stream the startup/shutdown, rethink it. And yes, I know third parties are involved too - *they* really need to lift their act.

And still slackware boots faster... and without systemd.

i think at this point it would be important to find out what op is actually trying to achieve, what the script does that makes it so important to run it FIRST at shutdown, or if the problem can be tackled differently.
http://xyproblem.info/

1 members found this post helpful.

systemd: nothing like adding complexity while removing functionality! Reminds me of ... Windows!

I run Slackware on my servers and am very happy with the good 'old, user-simple /etc/rc.d scripts. If you know how to write a bash script, you can do an init script AND put it in exactly the order you want. Anyway ...

OK, what are my alternative for Ubuntu 16.04? I noticed that when I installed sendmail, it created K01sendmail scripts in /etc/rc.[016]. Could I still use the init.d mechanism? Will that still execute scripts in sort order?

btw - the 2 lines HMW suggested I add to the unit file didn't work. The service didn't run at all. Could be a syntax issue or my not knowing how to edit/rerun a unit file, but if I have no control over the execution order, no sense in debugging that.

As to my objective, I am running a VirtualBox Windows 7 VM. If the VM is still running at reboot or shutdown time, it is as if the power cord is pulled on the VM and I get the "Start Windows Normally" option screen, potentially with disk corruptions to deal with. I want to send a command to shut it down gracefully at shutdown or reboot time (which I can do). However, I want to make sure this runs before the login task are terminated or all is for nought! The VM will be long gone before I get to the graceful shutdown.

just write a shutdown script that closes out the vm then turns off the system

1 members found this post helpful.

What ondoho and John VV said.

But if you want systemd to send the command, then add an After directive to {shutdown,halt,reboot}.service such that they can only run once your script has finished. Obviously make sure your script exits 0 if no VM is actually being shutdown.

That isn't any different than using the "Before" in the new service...

The problem is finding all the branches of the tree leading to the {shutdown, halt, reboot}.service

John VV's comment just restates my problem/issue. Not sure I understand what to do there. I have such a script, my problem is timing/order.

Hmmm, interesting idea. In checking my /lib/systemd/system/systemd-reboot.service I find it is symlinked to /dev/null. /lib/systemd/system/reboot.target has:
So, I think I need some guidance here. Do I create my own reboot.service? Do I need to create my VM shutdown script/unit to a "target"?

No.

Shutdown, halt and reboot are all handled internally to systemd.

There is no external actions that can be done. Everything has to be fitted into the dependency list - and as stated, finding the right place is not trivial.

Hmmmm - my attitude would be, "all you need to do is stop systemd-halt.service from running". Don't try and find all the holes to stick a finger in.
I'd be inclined to add a "RequiresMountFor" for something you know is there (/usr, /home, ... whatever) and use vboxmanage to clean up the guests. Then exit with a zero so systemd-halt can proceed.
Untested.