Re: [systemd-devel] after=user.slice not enforced

2016-11-24 Thread Michael Chapman

On Thu, 24 Nov 2016, Kai Krakow wrote:

Am Wed, 23 Nov 2016 09:14:34 +0100
schrieb Cédric BRINER :


Hi,

For the context, we are trying to stop a daemon launched by a user...


Hi,

sapRunning service contains a "After=user.slice". But at the
shutdown, a process (write-sysv-test.pl) running in user.slice is
killed before the end of the sapRunning's stop.


Slices are a concept for resource management, and that's what they
should be used for. Do not user them for anything else, such as
ordering purposes.

In systemd shutdown ordering is the inverse of start-up ordering,
and After= and Before= declare the latter. This means that if your
service has After=user.slice, this means at shutdown your service
will be stopped first and user.slice second.

Thanks for the clarification.

But this has not the expected impact. We were wishing with the
"After=user.slice", that the stop sapRunning will occur before any
user commands are stopped.

Does using "After=user.slice" propagate also on all the *childs*. That
way we could ensure that our stop services' commmand is launched as
the first ever before any kill ?

The question still remain for us, how can we do to have a daemon
launched by hand, that can be handled by systemd for its stopping.


I think you could maybe use targets as synchronizations points... Maybe
make a target that starts after multi-user.target and requires it. Then
put your service as wanted by this new target (maybe also using after
and requires), let's call it sap-started.target. Then make that the
default target at boot.

That way, on shutdown, it should first stop and wait for
sap-started.target, and only then pull down the rest of the system.


Simply ordering target units won't help. At boot, systemd does not wait 
for the first target to be reached before considering starting the units 
wanted by the second target. Similarly, at shutdown it will not wait for 
the second group of units to be stopped before stopping the first group of 
units -- indeed, the target units themselves could be stopped almost 
immediately.


What you can do is have something like this:

  [Unit]
  After=multi-user.target

  [Install]
  WantedBy=multi-user.target

Normally, this unit would be Before=multi-user.target (this is an 
implicit dependency added when a target Wants= something).
By adding an explicit After=multi-user.target dependency, however, you can 
override this.


A unit with this dependency will be "started late" and "stopped early".

However, this doesn't really do anything to order it with respect to user 
sessions. As described elsewhere in this thread, there's no clean way to 
do that.


- Michael___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] after=local-fs not enforced

2016-11-24 Thread Andrei Borzenkov
25.11.2016 00:50, Benoit SCHMID пишет:
> Hello,
> 
> 
> On 11/24/2016 08:14 PM, Andrei Borzenkov wrote:
>> What is blkdeactivate? It does not belong to systemd.
> 
> You are asking too much, for me, Andrei because it comes from RH repo :-)
> 

Well, it appears it is part of LVM2.

Version 2.02.98 - 15th October 2012
  Introduce blkdeactivate script to deactivate block devs with dependencies.


> I have found this on my host:
> 
> # cat /usr/lib/systemd/system/blk-availability.service
> [Unit]
> Description=Availability of block devices
> After=lvm2-activation.service lvm2-lvmetad.service
> iscsi-shutdown.service iscsi.service iscsid.service fcoe.service
> DefaultDependencies=no
> Conflicts=shutdown.target
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/true
> ExecStop=/usr/sbin/blkdeactivate -u -l wholevg -m disablequeueing

Yes, this is the command that tries to unmount filesystems on LVM2
devices, thus bypassing systemd normal dependencies. The idea of such
service is very questionable, but it is probably not something you can
really change.

You can try to add drop-in to order this service after
systemd-logind.service on shutdown, but I would contact RH and verify
that they agree to support this. In any case, this is not systemd issue.

> RemainAfterExit=yes
> 
> [Install]
> WantedBy=sysinit.target
> 
> # systemctl status blk-availability
> ● blk-availability.service - Availability of block devices
>Loaded: loaded (/usr/lib/systemd/system/blk-availability.service;
> disabled; vendor preset: disabled)
>Active: active (exited) since Thu 2016-11-24 15:25:32 CET; 7h ago
>   Process: 2653 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS)
>  Main PID: 2653 (code=exited, status=0/SUCCESS)
>CGroup: /system.slice/blk-availability.service
> 
> Nov 24 15:25:32 beryl5 systemd[1]: Starting Availability of block
> devices...
> Nov 24 15:25:32 beryl5 systemd[1]: Started Availability of block devices.
> 
> Is this enough to answer your question?
> 

Well,

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] after=user.slice not enforced

2016-11-24 Thread Kai Krakow
Am Wed, 23 Nov 2016 09:14:34 +0100
schrieb Cédric BRINER :

> Hi,
> 
> For the context, we are trying to stop a daemon launched by a user...
> 
> >> Hi,
> >>
> >> sapRunning service contains a "After=user.slice". But at the
> >> shutdown, a process (write-sysv-test.pl) running in user.slice is
> >> killed before the end of the sapRunning's stop.  
> > 
> > Slices are a concept for resource management, and that's what they
> > should be used for. Do not user them for anything else, such as
> > ordering purposes.
> > 
> > In systemd shutdown ordering is the inverse of start-up ordering,
> > and After= and Before= declare the latter. This means that if your
> > service has After=user.slice, this means at shutdown your service
> > will be stopped first and user.slice second.  
> Thanks for the clarification.
> 
> But this has not the expected impact. We were wishing with the
> "After=user.slice", that the stop sapRunning will occur before any
> user commands are stopped.
> 
> Does using "After=user.slice" propagate also on all the *childs*. That
> way we could ensure that our stop services' commmand is launched as
> the first ever before any kill ?
> 
> The question still remain for us, how can we do to have a daemon
> launched by hand, that can be handled by systemd for its stopping.

I think you could maybe use targets as synchronizations points... Maybe
make a target that starts after multi-user.target and requires it. Then
put your service as wanted by this new target (maybe also using after
and requires), let's call it sap-started.target. Then make that the
default target at boot.

That way, on shutdown, it should first stop and wait for
sap-started.target, and only then pull down the rest of the system.

But what's the purpose of stopping user processes only after this
service was stopped? This does make no sense to me. I'd instead define
proper dependencies.


-- 
Regards,
Kai

Replies to list-only preferred.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] after=local-fs not enforced

2016-11-24 Thread Benoit SCHMID

Hello,


On 11/24/2016 08:14 PM, Andrei Borzenkov wrote:

What is blkdeactivate? It does not belong to systemd.


You are asking too much, for me, Andrei because it comes from RH repo :-)

I have found this on my host:

# cat /usr/lib/systemd/system/blk-availability.service
[Unit]
Description=Availability of block devices
After=lvm2-activation.service lvm2-lvmetad.service 
iscsi-shutdown.service iscsi.service iscsid.service fcoe.service

DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/bin/true
ExecStop=/usr/sbin/blkdeactivate -u -l wholevg -m disablequeueing
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target

# systemctl status blk-availability
● blk-availability.service - Availability of block devices
   Loaded: loaded (/usr/lib/systemd/system/blk-availability.service; 
disabled; vendor preset: disabled)

   Active: active (exited) since Thu 2016-11-24 15:25:32 CET; 7h ago
  Process: 2653 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 2653 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/blk-availability.service

Nov 24 15:25:32 beryl5 systemd[1]: Starting Availability of block devices...
Nov 24 15:25:32 beryl5 systemd[1]: Started Availability of block devices.

Is this enough to answer your question?

Thanks for your help.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Script in /usr/lib/systemd/system-shutdown not executed on init 6

2016-11-24 Thread Kai Krakow
Am Thu, 24 Nov 2016 10:39:52 +0100
schrieb Benoit SCHMID :

> Hello,
> 
> On 11/23/2016 03:52 PM, Reindl Harald wrote:
> > so why do you strip the whole context and rest of the response?
> >
> > what  is your exactly problem?
> >  
> I think my original question on this thread is clear.
> > it should be no rocket science to define a service, order starting
> > as needed which ensures at the same time that stop services happens
> > in the exactly reverse order
> >  
> It is more than rocket science to have the same behaviour
> for my SAP system behaviour on RH7 like on RH6.
> On RH6 I could boot my server.
> Then a few days after I could manually restart dedicated processes.
> On the next shutdown, I knew my processes would be cleanly stopped.
> 
> With RH7, my commands' executions need to be wrapped by systemd
> service. Otherwise, as L. Poettering said, these daemons are not
> stopped cleanly at shutdown.
> This what I have understood.
> 
> > maybe you should stop looking at old sysv scripts and just start
> > from scratch and define what you need in a proper systemd unit -
> > for many things you will find out that a lot of magic from init
> > scripts is not needed at all
> >  
> This is what I am trying to do :-)
> 
> > for me it ssems what you trying to to is wrap everything from a init
> > script in a native systemd-unit which is wrong from the start in
> > most cases   
> "trying to wrap everything from init script" is not my overall goal.
> My over goal is to administer my SAP systems on my new RH7 servers.
> 
> I have constraints from RH7 and from SAP and from Oracle DB.
> After reading that there is systemv systemd generator,
> I thought that I could have all the old functionalities with systemd.
> It is not the case.
> Therefore I am trying to find the best compromises to run my SAP
> systems. This implies understanding what I can do and what I cannot
> do with systemd. This is why I ask questions like the one on this
> thread.

What exactly is the init script in question doing, not generalizing it
to a simple "echo" and "touch"?

I had once an init script that did dirty user switch hackery to first
setup some things, then switch the user and start the service by using
"su".

This does not seem to work properly as "su" spawns a new session. Your
service executable is then no longer a real part of what systemd knows
about spawning the service. During shutdown, it cannot properly stop it
(actually, it simply ignores the PID from the su session) and will
eventually simply kill it later. That means, the core of your service
looses all stop dependencies defined and will, by definition, killed
too late at shutdown.

Even OpenRC did not properly stop this service when used in cgroup
mode. Using su simply switches to another cgroup as it looked to me and
the service wasn't sent signals properly.

Instead, you should leave the setup and user switching to systemd. That
means setting up directories for example with "RuntimeDirectory", or do
some other stuff with "ExecPre". You can switch the user with a native
systemd directive, even switching only for "Exec" but not "ExecPre".

I my case, I ported the cumbersome script to native systemd mechanics
with proper user switching and now everything went well and was solid.

The original script was something like a start-stop-daemon emulation,
exporting a simple start/stop interface to command line, thus every
init system could be easily wrapped around it. Its core daemon is a
closed source piece of software and the "init" script was just a
convenience compatbility layer to sysvinit systems - but due to its
implementation incompatible with cgroup-based init systems.

-- 
Regards,
Kai

Replies to list-only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] after=local-fs not enforced

2016-11-24 Thread Andrei Borzenkov
24.11.2016 18:20, Benoit SCHMID пишет:
> Hello,
> 
> We have defined the following sap_XXX.service.
> It contains the following in [Unit]:
> ###
> After=local-fs.target network-online.target ora_lsnr_XXX.service
> remote-fs.target
> Wants=ora_lsnr_XXX.service
> ###
> 
> Stopping and Starting the service with systemd runs fine.
> 
> When we reboot, systemd umounts local file systems,
> before sap_XXX is stopped.
> This is done although there is After=local-fs.target.
> 
> What are we missing?
> 
> Above there is the output with a few substitutions (XXX and YYY).
>  http://pastebin.com/nLJ5Zbgj
> 

Nov 24 15:22:03 hostname blkdeactivate[12482]: [UMOUNT]: unmounting
vg_yyysap-lv_yyyap_sap (dm-21) mounted on /usr/sap/YYY... done

What is blkdeactivate? It does not belong to systemd.

> # systemctl --version
> systemd 219
> 
> Thanks for your answer.
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] after=local-fs not enforced

2016-11-24 Thread Benoit SCHMID
Hello,

On 11/24/2016 04:42 PM, Reindl Harald wrote:
>
> you *really* should post the whole systemd-unit instead pieces!
> have you played around with DefaultDependencies?

Here it is :-)
[Unit]
Description=SAP XXX
After=local-fs.target network-online.target ora_lsnr_XXX.service
remote-fs.target
Wants=ora_lsnr_XXX.service

[Service]
EnvironmentFile=/etc/default/sap_XXX
User=xxxadm
Group=sapsys
ExecStart=/sapmnt/XXX/exe/nuc/linuxx86_64/startsap
ExecStop=/sapmnt/XXX/exe/nuc/linuxx86_64/stopsap
Restart=no
TimeoutStopSec=5min
TimeoutStartSec=5min
Type=forking

[Install]
WantedBy=multi-user.target


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] after=local-fs not enforced

2016-11-24 Thread Reindl Harald



Am 24.11.2016 um 16:20 schrieb Benoit SCHMID:

We have defined the following sap_XXX.service.
It contains the following in [Unit]:
###
After=local-fs.target network-online.target ora_lsnr_XXX.service
remote-fs.target
Wants=ora_lsnr_XXX.service
###

Stopping and Starting the service with systemd runs fine.

When we reboot, systemd umounts local file systems,
before sap_XXX is stopped.
This is done although there is After=local-fs.target.

What are we missing?

Above there is the output with a few substitutions (XXX and YYY).
 http://pastebin.com/nLJ5Zbgj


you *really* should post the whole systemd-unit instead pieces!
have you played around with DefaultDependencies?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] after=local-fs not enforced

2016-11-24 Thread Benoit SCHMID
Hello,

We have defined the following sap_XXX.service.
It contains the following in [Unit]:
###
After=local-fs.target network-online.target ora_lsnr_XXX.service
remote-fs.target
Wants=ora_lsnr_XXX.service
###

Stopping and Starting the service with systemd runs fine.

When we reboot, systemd umounts local file systems,
before sap_XXX is stopped.
This is done although there is After=local-fs.target.

What are we missing?

Above there is the output with a few substitutions (XXX and YYY).
 http://pastebin.com/nLJ5Zbgj

# systemctl --version
systemd 219

Thanks 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] Script in /usr/lib/systemd/system-shutdown not executed on init 6

2016-11-24 Thread Lennart Poettering
On Thu, 24.11.16 10:59, Benoit SCHMID (benoit.sch...@unige.ch) wrote:

> Hello,
> 
> On 11/24/2016 12:22 AM, Lennart Poettering wrote:
> > In general, while systemd provides a large degree of SysV compat, in
> > the end we aren't SysV and thus we do not provide 100%. In cases like
> > this this becomes visible.
> 
> You are 100% right :-)
> 
> Right after upgrading my first server,
> I wrongly assumed that systemv scripts
> could be migrated easily.
> I was wrong.

Well, most of them can. It's the exotic ones which can't be that easily.

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] Script in /usr/lib/systemd/system-shutdown not executed on init 6

2016-11-24 Thread Benoit SCHMID
Hello,

On 11/24/2016 12:22 AM, Lennart Poettering wrote:
> In general, while systemd provides a large degree of SysV compat, in
> the end we aren't SysV and thus we do not provide 100%. In cases like
> this this becomes visible.

You are 100% right :-)

Right after upgrading my first server,
I wrongly assumed that systemv scripts
could be migrated easily.
I was wrong.

Thanks for all the feedbacks you have provided.

-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

 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] Started process not attach to its related service.

2016-11-24 Thread Benoit SCHMID
Hello,

On 11/23/2016 07:26 PM, Andrei Borzenkov wrote:
> Recent (for suitable definition of "recent") SAP releases are using
> sapcontrol framework to start/stop SAP services. So start startsap
> actually does, is to make remote procedure call to sapstartsrv which
> then starts SAP instance processes. So as long as startsapsrv itself is
> launched as separate service, your problem should not happen. This may
> offer suitable workaround.

You are reporting a useful point.

I can not do all my Oracle DB and SAP administration with sapstartsrv.
But this can cover a big part of the job as this daemon stay alive
even when a whole SAP instance is stopped.
I have to test how sapstartsrv preserve cgroup.

Thanks a lot for pointing out this :-)

-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

 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] Script in /usr/lib/systemd/system-shutdown not executed on init 6

2016-11-24 Thread Benoit SCHMID
Hello,

On 11/23/2016 03:52 PM, Reindl Harald wrote:
> so why do you strip the whole context and rest of the response?
>
> what  is your exactly problem?
>
I think my original question on this thread is clear.
> it should be no rocket science to define a service, order starting as
> needed which ensures at the same time that stop services happens in
> the exactly reverse order
>
It is more than rocket science to have the same behaviour
for my SAP system behaviour on RH7 like on RH6.
On RH6 I could boot my server.
Then a few days after I could manually restart dedicated processes.
On the next shutdown, I knew my processes would be cleanly stopped.

With RH7, my commands' executions need to be wrapped by systemd service.
Otherwise, as L. Poettering said, these daemons are not stopped cleanly
at shutdown.
This what I have understood.

> maybe you should stop looking at old sysv scripts and just start from
> scratch and define what you need in a proper systemd unit - for many
> things you will find out that a lot of magic from init scripts is not
> needed at all
>
This is what I am trying to do :-)

> for me it ssems what you trying to to is wrap everything from a init
> script in a native systemd-unit which is wrong from the start in most
> cases 
"trying to wrap everything from init script" is not my overall goal.
My over goal is to administer my SAP systems on my new RH7 servers.

I have constraints from RH7 and from SAP and from Oracle DB.
After reading that there is systemv systemd generator,
I thought that I could have all the old functionalities with systemd.
It is not the case.
Therefore I am trying to find the best compromises to run my SAP systems.
This implies understanding what I can do and what I cannot do with systemd.
This is why I ask questions like the one on this thread.

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