Re: [systemd-devel] Creating new targets to order shutdown
17.01.2017 18:21, Ray Nichols пишет: > 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=subject:%22%5C%5Bsystemd%5C-devel%5C%5D+after%3Duser.slice+not+enforced%22=newest=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. > > User processes belong to scope units. Scope units are created programmatically by logind and have predefined set of dependencies. There is no hooks to change it from logind side; and because names are not predictable (and do not use templates) it is not possible to use drop ins. So there is really no way to order anything against user sessions unless you patch logind source. Thanks for that. Yes, the kind of service that I'm wanting to manage can have literally hundreds of user sessions created for it. The stop script I have can cleanly handle this easily *but* must not run in parallel with any other shutting down of service units or removal of user sessions. Is it the case that this use-case on Linux must be handled outside of systemd? (I'm not even sure what alternative that might be as yet.) My own experience is with Oracle databases but other databases like PostgreSQL and MySQL will surely have similar requirements here. I'm obviously keen for all server shutdown initiation approaches to work and not have a shell script wrapper around the shutdown call to do some work first. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating new targets to order shutdown
17.01.2017 18:21, Ray Nichols пишет: > 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=subject:%22%5C%5Bsystemd%5C-devel%5C%5D+after%3Duser.slice+not+enforced%22=newest=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. > > User processes belong to scope units. Scope units are created programmatically by logind and have predefined set of dependencies. There is no hooks to change it from logind side; and because names are not predictable (and do not use templates) it is not possible to use drop ins. So there is really no way to order anything against user sessions unless you patch logind source. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating new targets to order shutdown
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=subject:%22%5C%5Bsystemd%5C-devel%5C%5D+after%3Duser.slice+not+enforced%22=newest=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@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and hardware real time clock
Hello. I am aware of the fact that systemd relies on the kernel to set system clock from hardware clock, and that requires compiling rtc drivers into the kernel, not as modules. I am also aware that doing it othervise would mix timestamps in log entries. The question is: if I have rtc driver as a module anyway, how to modify initramfs so that system time would be set, in such a way so that it happens *before* journald in initramfs starts? I assume it is an initramfs using systemd inside of it. One approach would be to have an udev rule that does trigger after rtc appears or rtc symlink is added, this rule would start a service that sets the system clock, but this service would have to always run before journald, and that seems not possible in such a configuration, because if someone would unplug the rtc the service would not run? Another thing is to load rtc and i2c bus module where rtc is connected statically without udev detection, and then the hwclock service would always be triggered before journald without looking for rtcs appearing... signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel