LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 08-28-2016, 11:13 AM   #1
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,789

Rep: Reputation: 139Reputation: 139
How to run systemd service first


I have the following systemd unit:
Code:
[Unit]
Description=local shutdown

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/etc/rc.local_shutdown

[Install]
WantedBy=multi-user.target
I want to make sure this runs before all other shutdown services. How do I do that?
 
Old 08-28-2016, 01:00 PM   #2
HMW
Member
 
Registered: Aug 2013
Location: Sweden
Distribution: Debian, Arch, Red Hat, CentOS
Posts: 773
Blog Entries: 3

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
Quote:
Originally Posted by mfoley View Post
I have the following systemd unit:
Code:
[Unit]
Description=local shutdown

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/etc/rc.local_shutdown

[Install]
WantedBy=multi-user.target
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:
Code:
[Unit]
Description=local shutdown
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[ ... the rest of your stuff ... ]
Try it out and see if it works on your system.

Best regards,
HMW
 
Old 08-28-2016, 09:21 PM   #3
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,853

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
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.
 
Old 08-29-2016, 04:34 AM   #4
HMW
Member
 
Registered: Aug 2013
Location: Sweden
Distribution: Debian, Arch, Red Hat, CentOS
Posts: 773
Blog Entries: 3

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
Quote:
Originally Posted by jpollard View Post
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.
Good point!
 
Old 08-29-2016, 05:27 AM   #5
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,853

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
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.

Last edited by jpollard; 08-29-2016 at 05:29 AM.
 
Old 08-29-2016, 08:49 AM   #6
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,098

Rep: Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326
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.
 
Old 08-29-2016, 09:26 AM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,853

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
Quote:
Originally Posted by syg00 View Post
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.
 
Old 08-29-2016, 11:24 AM   #8
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 15,305
Blog Entries: 9

Rep: Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379Reputation: 4379
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.
Old 08-29-2016, 01:19 PM   #9
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,789

Original Poster
Rep: Reputation: 139Reputation: 139
Quote:
Originally Posted by jpollard
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.
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.

Last edited by mfoley; 08-29-2016 at 01:30 PM.
 
Old 08-29-2016, 07:52 PM   #10
John VV
LQ Muse
 
Registered: Aug 2005
Location: A2 area Mi.
Posts: 17,502

Rep: Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617
just write a shutdown script that closes out the vm then turns off the system
 
1 members found this post helpful.
Old 08-29-2016, 08:24 PM   #11
notKlaatu
Senior Member
 
Registered: Sep 2010
Location: Lawrence, New Zealand
Distribution: Slackware
Posts: 1,075

Rep: Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725
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.
 
Old 08-29-2016, 08:52 PM   #12
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,853

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
Quote:
Originally Posted by notKlaatu View Post
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

Last edited by jpollard; 08-29-2016 at 08:54 PM.
 
Old 08-29-2016, 08:56 PM   #13
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,789

Original Poster
Rep: Reputation: 139Reputation: 139
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.

Quote:
Originally Posted by notKlaatu View Post
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.
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:
Code:
[Unit]
Description=Reboot
Documentation=man:systemd.special(7)
DefaultDependencies=no
Requires=systemd-reboot.service
After=systemd-reboot.service
AllowIsolate=yes
JobTimeoutSec=30min
JobTimeoutAction=reboot-force

[Install]
Alias=ctrl-alt-del.target
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"?
 
Old 08-29-2016, 09:03 PM   #14
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,853

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
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.
 
Old 08-29-2016, 09:16 PM   #15
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,098

Rep: Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326Reputation: 3326
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.
 
  


Reply

Tags
shutdow, systemd


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Systemd service: AUTOSSH.service does not start at boot, how can I fix this? The_Linux_Machine Linux - Newbie 1 07-06-2016 12:00 PM
Can't access full journalctl from script via systemd service even though user is in systemd-journal group iwtbf Linux - Newbie 0 02-19-2016 02:44 PM
systemd service aagaag Linux - Newbie 1 01-18-2016 07:42 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 06:03 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration