Re: [systemd-devel] systemd-sysv-generator bug ?
On Mon, 28.11.16 15:28, Cédric BRINER (cedric.bri...@unige.ch) wrote: > To summarize our understanding: > - you cannot use systemd to stop a daemon that was not started with a > systemd tools. Daemon launched with systemd could be one: > - with a .service on systemd > - launched with systemd-run > > So if you log into a terminal and launch the daemon with a > /usr/bin/my_daemon &, you will not able to stop it with systemd. Asthe > daemon will be attached to user.slice. > > Moving the start and the stop to a service, solved everything. Yupp, all of the above sounds correct! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
To summarize our understanding: - you cannot use systemd to stop a daemon that was not started with a systemd tools. Daemon launched with systemd could be one: - with a .service on systemd - launched with systemd-run So if you log into a terminal and launch the daemon with a /usr/bin/my_daemon &, you will not able to stop it with systemd. Asthe daemon will be attached to user.slice. Moving the start and the stop to a service, solved everything. Regards. Cedric BRINER P.-S. Thanks for the fast and helpfull response of the mailing list. -- Cédric BRINER, Ing. EPFL & HES +41 (0)22 / 379 71 83 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
22.11.2016 12:34, Benoit SCHMID пишет: > Hello, > > On 11/22/2016 09:15 AM, Andrei Borzenkov wrote: >> Assuming that your command survives normal session exit - does adding >> "After=user.slice" to your service helps? This should ensure your >> service is stopped before any user processes. > > With "After=system.slice local-fs.target network-online.target > systemd-journald.socket user.slice basic.target", > my process is still killed by systemd before my stop script is started. > Yes, it was my mistake. There is no systemd service unit *after* user sessions on startup (nor is it logically possible, as user sessions come and go). User session is represented by session-NNN.scope unit. On shutdown these units are stopped as soon as possible, according to general systemd behavior. These units are created on demand by logind; they have fixed dependencies, you cannot change them. It /may/ be possible to use drop-ins, except these names are not known in advance. There is no easy way to order something to be stopped first, just as there is no easy way to order something to be started last using systemd. It is possible to override special targets (poweroff.target etc) to pull in special service that will then trigger actual poweroff etc. This effectively means overriding vendor supplied systemd confguration; I doubt SAP would ever accept it as supported solution. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
Hello, On 11/22/2016 09:15 AM, Andrei Borzenkov wrote: > Assuming that your command survives normal session exit - does adding > "After=user.slice" to your service helps? This should ensure your > service is stopped before any user processes. With "After=system.slice local-fs.target network-online.target systemd-journald.socket user.slice basic.target", my process is still killed by systemd before my stop script is started. This is my process status, before running init 6: CGroup: / ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 2 ├─user.slice │ ├─user-0.slice │ │ └─session-2.scope │ │ ├─15483 sshd: root@pts/0 │ │ ├─15485 -bash │ │ ├─15783 /usr/bin/perl /usr/local/bin/write-sysv-test.pl │ │ ├─15800 systemctl status │ │ └─15801 less # systemctl status sysv-test.service ● sysv-test.service - sysv-test Loaded: loaded (/etc/systemd/system/sysv-test.service; enabled; vendor preset: disabled) Active: active (exited) since Tue 2016-11-22 10:18:39 CET; 12min ago Process: 13688 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS) Main PID: 13688 (code=exited, status=0/SUCCESS) CGroup: /system.slice/sysv-test.service Nov 22 10:18:39 spinelle1 systemd[1]: Started sysv-test. Nov 22 10:18:39 spinelle1 systemd[1]: Starting sysv-test... # systemctl show sysv-test.service | grep -i after RemainAfterExit=yes After=system.slice local-fs.target network-online.target systemd-journald.socket user.slice basic.target Would you know why it is still killed before running my stop script? Regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
Hello, On 11/22/2016 10:25 AM, Andrei Borzenkov wrote: > I do not think so, unless you have explicit dependencies on mount > points (they are commented out in your link). If you do have explicit > dependencies, I expect this to work too. Even, when the line is uncommented, the umounts are performed. How can I diagnose why it is unmounted before my stop script ends? As these filesystem are local in my /etc/fstab, do you agree that "After=local-fs.target" should be enough to avoid unmounting before my stopexec finishes? Thanks in advance for your answer. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
On Tue, Nov 22, 2016 at 12:21 PM, Benoit SCHMID wrote: > Hello, > > On 11/22/2016 09:15 AM, Andrei Borzenkov wrote: >> Mount units are also propagated to systemd user instance. So you >> probably can also run this unit in systemd user context and have usual >> dependencies on filesystems (like RequiresMountsFor) - at least, I >> think so :) You will need to enable lingering then as mentioned >> already. User instances are stopped on shutdown too. > > Do you mean that adding "After=user.slice" would also prevent systemd to > unmount > fs before my stop command is finished? > I do not think so, unless you have explicit dependencies on mount points (they are commented out in your link). If you do have explicit dependencies, I expect this to work too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
Hello, On 11/22/2016 09:15 AM, Andrei Borzenkov wrote: > Mount units are also propagated to systemd user instance. So you > probably can also run this unit in systemd user context and have usual > dependencies on filesystems (like RequiresMountsFor) - at least, I > think so :) You will need to enable lingering then as mentioned > already. User instances are stopped on shutdown too. Do you mean that adding "After=user.slice" would also prevent systemd to unmount fs before my stop command is finished? Thanks in advance for your answer. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
On Tue, Nov 22, 2016 at 10:38 AM, Cédric BRINER wrote: > Hi, > > We have been through a lot of tests, trying to make it reproductible > with some easy scripts. You'll see at the bottom of this email, some > links on the scripts used, what we have typed in our console, and the > output of journalctl -b -1 > >> systemd will only stop services at shutdown that are running. That >> means you need to make sure your SysV script is properly hooked into >> the start runlevels too, even if its start verb is just a nop. > Mixing your comment, and the one from Reindl HARALD, we have a > sysv-test.service which has /usr/bin/true for ExecStart, and a > stop-sysv-test.bash for ExecStop which stops a daemon launched within > the console. > > Before the init 6 we had: > # systemctl status sysv-test > ● sysv-test.service - sysv-test >Loaded: loaded (/etc/systemd/system/sysv-test.service; enabled; > vendor preset: disabled) >Active: active (exited) since lun 2016-11-21 15:03:23 CET; 12min ago > Main PID: 2562 (code=exited, status=0/SUCCESS) >CGroup: /system.slice/sysv-test.service > > nov 21 15:03:23 beryl5 systemd[1]: Started sysv-test. > nov 21 15:03:23 beryl5 systemd[1]: Starting sysv-test... > > > Now, when you look at the journalctl, you'll see that before the > ExecStop starts: > * write-sysv-test.pl is killed. > * the fs /oracle/BAS/oraarch a "local-fs" is already unmounted. > Script that you start manually runs as part of login session and is stopped concurrently with your service. So the first problem is, it will be probably killed by logind when session terminates (user exits), at least this is what current systemd version does by default. It is possible to use systemd-run to start process in different scope (outside of current session), then you still need to enable lingering for this user. Assuming that your command survives normal session exit - does adding "After=user.slice" to your service helps? This should ensure your service is stopped before any user processes. > > The difficulty that we have, is how to have a daemon, no launched by > systemd that can stop nicely by: > - having its filesystem during the stop of the daemon. > - able to use a stop script. > Mount units are also propagated to systemd user instance. So you probably can also run this unit in systemd user context and have usual dependencies on filesystems (like RequiresMountsFor) - at least, I think so :) You will need to enable lingering then as mentioned already. User instances are stopped on shutdown too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
Hi, We have been through a lot of tests, trying to make it reproductible with some easy scripts. You'll see at the bottom of this email, some links on the scripts used, what we have typed in our console, and the output of journalctl -b -1 > systemd will only stop services at shutdown that are running. That > means you need to make sure your SysV script is properly hooked into > the start runlevels too, even if its start verb is just a nop. Mixing your comment, and the one from Reindl HARALD, we have a sysv-test.service which has /usr/bin/true for ExecStart, and a stop-sysv-test.bash for ExecStop which stops a daemon launched within the console. Before the init 6 we had: # systemctl status sysv-test ● sysv-test.service - sysv-test Loaded: loaded (/etc/systemd/system/sysv-test.service; enabled; vendor preset: disabled) Active: active (exited) since lun 2016-11-21 15:03:23 CET; 12min ago Main PID: 2562 (code=exited, status=0/SUCCESS) CGroup: /system.slice/sysv-test.service nov 21 15:03:23 beryl5 systemd[1]: Started sysv-test. nov 21 15:03:23 beryl5 systemd[1]: Starting sysv-test... Now, when you look at the journalctl, you'll see that before the ExecStop starts: * write-sysv-test.pl is killed. * the fs /oracle/BAS/oraarch a "local-fs" is already unmounted. The difficulty that we have, is how to have a daemon, no launched by systemd that can stop nicely by: - having its filesystem during the stop of the daemon. - able to use a stop script. Thanks in advance for your help. [1] scripts_n_console.txt lists the scripts used for the test, and shows the command done on the console http://pastebin.com/UWJhrWUD [2] journalctl -b -1 http://pastebin.com/GKVVbuVg > Lennart Cédric BRINER P.-S. Lennart: sorry for the resent -- Cédric BRINER, Ing. EPFL & HES +41 (0)22 / 379 71 83 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
On Fri, 18.11.16 15:46, Cédric BRINER (cedric.bri...@unige.ch) wrote: > Hi, > > We used to have a custom init script written for systemV that was working. > > Now, for some unknown reason, systemd does not to treat this init script > as it used to be. > > The init script is a bit odd, as it does not start the daemon itself. > This task is done by an admin that launches it through the console. This > step does not interact with the init script nor with systemd. > > So the init script is mainly used, to stop the daemon nicely. > > With systemd, some filesystems (local_fs) that supports the database of > this daemon are unmounted before the stop command of the daemon starts. > This corrupts our database. > > It *feels* that systemd considers an init script-stop to follow the Unit > contraints only if the service is in a certain state. Which is not the > case for systemV and for our case :/ > > So... am I a bit right on this topic? > > If so how can I instruct this service to execute the ExecStop before > unmounting the local_fs. And don't tell me to specify RequiresMountsFor > with the listing of mount, as this has been tested with no success. systemd will only stop services at shutdown that are running. That means you need to make sure your SysV script is properly hooked into the start runlevels too, even if its start verb is just a nop. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysv-generator bug ?
Am 18.11.2016 um 15:46 schrieb Cédric BRINER: We used to have a custom init script written for systemV that was working. Now, for some unknown reason, systemd does not to treat this init script as it used to be If so how can I instruct this service to execute the ExecStop before unmounting the local_fs. first by replace that crap by a systemd-unit and if it does nothing else than call the shellscript in ExecStart and ExecStop second as you say it's only used at shutdown then it don't need ExecStart at all, just Type=oneshot and ExecStop, you can also use ExecStart=/bin/true for such cases and finally: order you After/Before correctly since stop of services at shutdown happens in the exactly reversed ordering than their start at boot which should make it pretty clear And don't tell me to specify RequiresMountsFor with the listing of mount, as this has been tested with no success that sentence is worthless without saying waht you have tried dozens of times people are coming here with RequiresMountsFor=/var/run not realizing that this is a symlink to /run and so never can do what one thinks it does because they symlink exists in different lifecycles times than mounts where it points to ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-sysv-generator bug ?
Hi, We used to have a custom init script written for systemV that was working. Now, for some unknown reason, systemd does not to treat this init script as it used to be. The init script is a bit odd, as it does not start the daemon itself. This task is done by an admin that launches it through the console. This step does not interact with the init script nor with systemd. So the init script is mainly used, to stop the daemon nicely. With systemd, some filesystems (local_fs) that supports the database of this daemon are unmounted before the stop command of the daemon starts. This corrupts our database. It *feels* that systemd considers an init script-stop to follow the Unit contraints only if the service is in a certain state. Which is not the case for systemV and for our case :/ So... am I a bit right on this topic? If so how can I instruct this service to execute the ExecStop before unmounting the local_fs. And don't tell me to specify RequiresMountsFor with the listing of mount, as this has been tested with no success. Regards. Cédric BRINER systemd 219 -- Cédric BRINER, Ing. EPFL & HES +41 (0)22 / 379 71 83 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel