Printable View
When I shutdown F24 server, it shows a stop job for /mnt/mymount for 90 seconds and repeats after time expires. I have to power off the system. The mount is using a openvpn client connection.
If I umount /mnt/mymount then shutdown is completed immediately.
I have tried putting a script in /usr/lib/systemd/system-shutdown folder but it does not run at shutdown. I can run the script manually and then shutdown will complete.
How do I run umount before shutdown?
That approach (in /usr/lib/systemd/system-shutdown DIRECTORY) looks like the right thing. Did you set the permissions and SELinux context ?Quote:
Originally Posted by gjaltemba
(on F23)
systemd binary documentation is dodgey, but I'd name the file something.shutdown just to avoid questions that only a source code review can resolve.Code:[stevea@hypoxylon system-shutdown]$ ls -lZ /usr/lib/systemd/system-shutdown
total 4
-rwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 164 Jun 3 10:18 mdadm.shutdown
Thank you for your help with my shutdown problem.
ls -lZ shows
unconfined_u:object_r:lib_t:s0
NOT
system_u:object_r:lib_t:s0
Tried restorecon -v but it does not change. What to do?
Not sure about your problem, but there are couple of issues about your approach of solving it.
The predefined directory for administrator's unit files is /etc/systemd/system/, /usr/lib/systemd/ is reserved for packages. And there goes only systemd "units", not scripts - systemd does not run scripts directly. You can put your script in /usr/local/bin or similar and reference it from systemd unit file.
If you are talking about SysV service script you can put it in /etc/init.d and systemd will happily manage it as its own.
Problem
Need to start F24 server in this order
1. network
2. openvpn client
3. fstab mount over vpn tunnel
By using x-systemd.automount, the startup works because the mounts only occur on first use.
At shutdown, it is important to unmount before closing openvpn client otherwise system hangs.
The only solution that I have is to manually umount before a shutdown. Ideally, the unmount job at shutdown should execute before openvpn client is closed.
How done?
In your .automount "After=" and "Requires" option can be specified to make it dependent on openvpn@.service and systemd should take care of the rest.
Thank you semiRocket. You the man.
After reading up on systemd-fstab-generator I was able to modify my fstab to include x-systemd.requires and x-systemd.after for openvpn@mymount.service. Now my shutdown is quick and smooth.
snippet from fstab
,x-systemd.requires=openvpn@myvpn.service,x-systemd.after=openvpn@myvpn.service,x-systemd.automount,
systemctl show -p Requires mnt-mymount.automount
Requires=-.mount openvpn@myvpn.service
systemctl show -p After mnt-mymount.automount
After=-.mount openvpn@myvpn.service
Glad that helped.
Including systemd options in /etc/fstab is a neater solution, thanks for reporting back. :)
EDIT: It seems you only need x-systemd.requires option in /etc/fstab:
Quote:
x-systemd.requires=
Configures a Requires= and an After= dependency between the created mount unit and another systemd unit, such as a device or
mount unit. The argument should be a unit name, or an absolute path to a device node or mount point. This option may be
specified more than once. This option is particularly useful for mount point declarations that need an additional device to
be around (such as an external journal device for journal file systems) or an additional mount to be in place (such as an
overlay file system that merges multiple mount points). See After= and Requires= in systemd.unit(5) for details.
Less is more. Thank you.
It works without x-systemd.after but the generator output has a subtle change.
snippet from fstab
,x-systemd.requires=openvpn@myvpn.service,x-systemd.automount,
systemctl show -p Requires mnt-mymount.automount
Requires=openvpn@myvpn.service -.mount
systemctl show -p After mnt-mymount.automount
After=openvpn@myvpn.service -.mount
Where is that documented, please.Quote:
Originally Posted by semiRocket
Would you PLEASE document your claim that this placement of a script is invalid - b/c someone then needs to file a bunch of bugzillas against numerous system packages.Quote:
And there goes only systemd "units", not scripts
orCode:[stevea@hypoxylon ~]$ cat /usr/lib/systemd/system-shutdown/mdadm.shutdown
#!/bin/sh
# We need to ensure all md arrays with external metadata
# (e.g. IMSM, DDF) are clean before completing the shutdown.
/usr/sbin/mdadm --wait-clean --scan
I appreciate that you created a much better solution to the OPs problem- but systemd remains IMO woefully documented, and you making unsupported personal claims about how it should work (in ways that defy RH practice) isn't helping.Code:[stevea@hypoxylon ~]$ grep -r "^#!" /usr/lib/systemd/
/usr/lib/systemd/system-generators/anaconda-generator:#!/bin/bash
/usr/lib/systemd/system-generators/kdump-dep-generator.sh:#!/bin/sh
/usr/lib/systemd/system-shutdown/mdadm.shutdown:#!/bin/sh
/usr/lib/systemd/fedora-dmraid-activation:#!/bin/bash
/usr/lib/systemd/fedora-autorelabel:#!/bin/bash
/usr/lib/systemd/fedora-domainname:#!/usr/bin/bash
/usr/lib/systemd/fedora-import-state:#!/bin/bash
/usr/lib/systemd/fedora-loadmodules:#!/bin/bash
/usr/lib/systemd/fedora-readonly:#!/bin/bash
/usr/lib/systemd/systemd-sanlock:#!/bin/bash
/usr/lib/systemd/systemd-wdmd:#!/bin/bash
For example "man systemd-shutdown" documents some limited features of the binary, but says nothing about the appropriate way to add administrative features to the shutdown event.
Dear stevea,
Please look into "man systemd.service" for the documented location of services location.
Quote:
Configuration Directories and Precedence
The default configuration is defined during compilation, so a configuration file is only needed when it is necessary to deviate from those defaults. By default, the configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. This file can be edited to create local overrides.
When packages need to customize the configuration, they can install configuration snippets in /usr/lib/systemd/*.conf.d/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. The main configuration file is read before any of the configuration directories, and has the lowest precedence; entries in a file in any configuration directory override entries in the single configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of which of the subdirectories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name takes precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.
To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.
For the scripts I didn't read it anywhere. I though it as a common sense to not mix up units and binaries. As you can take a look at how units run their binary services "grep ExecStart /usr/lib/systemd/system/*". I don't know what that does that you provided so I can't comment on that.
Also, as I understand almost whole /usr is reserved for packages only with the exception of /usr/local. http://www.tldp.org/LDP/Linux-Filesy.../html/usr.html.