Re: [systemd-devel] systemd-sysv-generator bug ?

[Lennart Poettering]

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 ?

[Cédric BRINER]

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 ?

[Andrei Borzenkov]

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 ?

[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.

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 ?

[Benoit SCHMID]

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 ?

[Andrei Borzenkov]

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 ?

[Benoit SCHMID]

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 ?

[Andrei Borzenkov]

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 ?

[Cédric BRINER]

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 ?

[Lennart Poettering]

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 ?

[Reindl Harald]

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 ?

[Cédric BRINER]

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