[systemd-devel] Creating new targets to order shutdown
Ray Nichols
ray.nichols at piksel.com
Tue Jan 17 15:21:14 UTC 2017
Hello,
I'm interested in a particular scenario which has been mentioned on mailing lists before:
https://www.mail-archive.com/search?l=systemd-devel@lists.freedesktop.org&q=subject:%22%5C%5Bsystemd%5C-devel%5C%5D+after%3Duser.slice+not+enforced%22&o=newest&f=1
about stopping a database service. For the moment I'm considering the simplest case where systemd controls both the start and stopping of the service (though I'm mainly interested in the stop).
What I'm finding in testing is that I cannot find an approach that stops the service before its user processes get killed first.
Following the discussion in the article above I planned to have an additional target that existed after multi-user.target - post-multi-user.target (a bit like graphical.target). The new target initially seemed like over-kill but I thought it would be the best way to order the shutdown.
[root at lab01 ~]# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
post-multi-user.target @42.912s
└─multi-user.target @42.911s
└─postfix.service @41.143s +1.766s
└─network.target @41.121s
└─network.service @39.661s +1.457s
...
I find that stopping and starting the service works fine as does isolating the target (actual config below) e.g.
e.g.
# systemctl stop dbora.service
# systemctl start dbora.service
# systemctl isolate multi-user.target
# systemctl isolate post-multi-user.target
But if I reboot I can see from the logs that a key process has gone before the shutdown script has run. This means the database has not had a chance to have a clean shutdown.
Is the scenario I'm after something I can configure for? I'm sure it would be a popular use case. I can't have the sessions I see in CGROUP name=systemd:/user.slice/ being killed before my stop script has completed - it has to hold-up that process.
My test configuration looks like:
lab01.localdomain-root [] /lib/systemd/system# systemctl get-default
post-multi-user.target
lab01.localdomain-root [] /lib/systemd/system# cat dbora.service
[Unit]
Description=The Oracle Database Service
Requires=post-multi-user.target
After=post-multi-user.target
[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
# Set this to something larger if it has an impact
TimeoutStopSec=0
ExecStart=/u01/app/oracle/product/12.1.0.2/dbhome_1/bin/dbora start
ExecStop=/u01/app/oracle/product/12.1.0.2/dbhome_1/bin/dbora stop
[Install]
# Puts wants directive for the other units in the relationship
WantedBy=post-multi-user.target
lab01.localdomain-root [] /lib/systemd/system# cat post-multi-user.target
[Unit]
Description=A level after multi-user for e.g. databases to run in
Requires=multi-user.target
Wants=dbora.service
After=multi-user.target
AllowIsolate=yes
Sanity check config:
lab01.localdomain-root [] /lib/systemd/system# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After post-multi-user.target
Requires=multi-user.target
Requisite=
Wants=systemd-readahead-replay.service systemd-readahead-collect.service dbora.service
BindsTo=
PartOf=
Before=systemd-readahead-done.service systemd-readahead-done.timer dbora.service
After=multi-user.target
lab01.localdomain-root [] /lib/systemd/system# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After dbora.service
Requires=basic.target post-multi-user.target
Requisite=
Wants=system.slice
BindsTo=
PartOf=
Before=shutdown.target
After=post-multi-user.target system.slice systemd-journald.socket basic.target
lab01.localdomain-root [] /lib/systemd/system#
lab01.localdomain-root [] /lib/systemd/system# systemd-analyze verify dbora.service
lab01.localdomain-root [] /lib/systemd/system# systemd-analyze verify post-multi-user.target
lab01.localdomain-root [] /lib/systemd/system#
Thanks,
Ray Nichols
Oracle DBA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170117/1f516896/attachment.html>
More information about the systemd-devel
mailing list