[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