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

[Kai Krakow]

Am Thu, 24 Nov 2016 10:39:52 +0100
schrieb Benoit SCHMID <Benoit.Schmid at unige.ch>:

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