Re: [systemd-devel] Started process not attach to its related service.

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

[Andrei Borzenkov]

23.11.2016 11:08, Benoit SCHMID пишет:
> Hello,
> 
> On 11/22/2016 11:46 AM, Holger Kiehl wrote:
>> But users do test things under their login environment and expect them
>> to run in this environment. So for some applications this is a must.
> I fully agree with you.
> 
> I am a SAP admin.
> 
> As far as SAP is concerned, to manage the service, the procedure is
> to issue sidadm user and start commands with different arguments
> from this shell user.
> 

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.

> I am not saying that it is the best way to do :-)
> I am just saying it is the way SAP works on all its Unix OS.
> This is why it is convenient to use su even if it has drawbacks.
> 
> On the other hand saying stop using su on your start/stop script
> is a limitation that I also find too strong.
> 
> Anyway thanks for all the ones who provided help and provided alternatives.
> I have not yet tested runuser and EnvironmentFile...
> 
> Regards,
> 

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

[Benoit SCHMID]

Hello,

On 11/22/2016 11:46 AM, Holger Kiehl wrote:
> But users do test things under their login environment and expect them
> to run in this environment. So for some applications this is a must.
I fully agree with you.

I am a SAP admin.

As far as SAP is concerned, to manage the service, the procedure is
to issue sidadm user and start commands with different arguments
from this shell user.

I am not saying that it is the best way to do :-)
I am just saying it is the way SAP works on all its Unix OS.
This is why it is convenient to use su even if it has drawbacks.

On the other hand saying stop using su on your start/stop script
is a limitation that I also find too strong.

Anyway thanks for all the ones who provided help and provided alternatives.
I have not yet tested runuser and EnvironmentFile...

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

[Benoit SCHMID]

Hello,

On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
>
> It's now 2016, and the first rule for migrating to systemd applies
> even to Oracle softwares.
>
> * http://jdebp.eu./FGA/systemd-house-of-horror/daemonize.html#first-rule
>
> * http://www.server-world.info/en/note?os=CentOS_7=oracle12c=6
>
> *
> https://lists.freedesktop.org/archives/systemd-devel/2014-October/thread.html#24663
>
> * https://www.realdbamagic.com/automatic-db-startup-linux-part-oel-6-7-2/
>

Even if we are in 2016, I have migrated a SAP system running on Oracle.
This not only a Oracle DB.

Everything worked fine on RH6 with system V.
On RH7 I am loosing several days try to understand
why systemd kills my process before I have the chance
to stop them on my own :-(

Finding out why it behaves like this is really not trivial, at least for me.
If there is an easy way to why I have such behaviour do not hesitate to
provide me the solution.
I will offer you a coffe next time you go to Geneva.

You have provided example of systemd config for Oracle DB.
If you have systemd configurations to start/stop a SAP system running on
Oracle DB,
please provide them to me.
I am very interesting.

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

[Lennart Poettering]

On Tue, 22.11.16 09:39, Benoit SCHMID (benoit.sch...@unige.ch) wrote:

> Good morning,
> 
> This topic is related to the systemd-sysv-generator thread submited by
> my colleague.
> I post it with another subject becaus I prefer to create another thread
> as it would make too many different questions in the same thread.
> 
> 1. I have defined a service.
> It is started by systemd on boot:
> # systemctl status sap
> ● sap.service - SYSV: Startup/Shutdown SAP and Oracle Listener
>Loaded: loaded (/etc/rc.d/init.d/sap; bad; vendor preset: disabled)
>Active: active (exited) since Tue 2016-11-22 09:22:23 CET; 3min 7s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 14124 ExecStart=/etc/rc.d/init.d/sap start (code=exited,
> status=0/SUCCESS)
> 
> 2. This service starts /etc/rc.d/init.d/sap start.
> % cat /etc/rc.d/init.d/sap
> #!/bin/bash
> ...
> case "$1" in
> start)
> # Oracle listener and instance startup
> echo -n "Starting Oracle Listener: "
> su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102
> /oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"

You are using "su" to change users here. "su" does considerably more
than that though: it opens a new login session. Use util-linux'
"setpriv" which is the tool to use if all you want to do is drop
privs...

That said, I'd always recommend stopping using SysV services all together.

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

[Benoit SCHMID]

Hello,

I have tried with
"User=oracle","Environment=ORACLE_HOME=/oracle/XXX/12102" and removing
the "su -".
You are right.
Now I have:

# systemctl status ora_lsnr_XXX.service
● ora_lsnr_XXX.service - Oracle Listener XXX
   Loaded: loaded (/etc/systemd/system/ora_lsnr_XXX.service; disabled;
vendor preset: disabled)
   Active: active (running) since Tue 2016-11-22 11:49:13 CET; 5min ago
  Process: 22841 ExecStart=/oracle/XXX/12102/bin/lsnrctl start
LISTENER_XXX (code=exited, status=0/SUCCESS)
 Main PID: 22843 (tnslsnr)
   CGroup: /system.slice/ora_lsnr_XXX.service
   └─22843 /oracle/XXX/12102/bin/tnslsnr LISTENER_XXX -inherit

Thanks for you help on this point.


On 11/22/2016 10:29 AM, Andrei Borzenkov wrote:
> On Tue, Nov 22, 2016 at 11:39 AM, Benoit SCHMID  
> wrote:
> ...
>> 2. This service starts /etc/rc.d/init.d/sap start.
>> % cat /etc/rc.d/init.d/sap
>> #!/bin/bash
>> ...
>> case "$1" in
>> start)
>> # Oracle listener and instance startup
>> echo -n "Starting Oracle Listener: "
>> su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102
>> /oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"
> ...
>> Why is the processed attached to user-.slice instead of sap?
> Because "su" opens new session with logind, so everything it does
> belongs to this user session. You should really use proper systemd
> unit and set User and Group for it instead.

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

 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.

[Holger Kiehl]

On Tue, 22 Nov 2016, Mantas Mikulėnas wrote:

> So, uh, that sounded like you value updating one file less (and even mixing
> user and daemon configs) above having the service actually work?
>
But users do test things under their login environment and expect them
to run in this environment. So for some applications this is a must.

> Not that it's an excuse anyway. Systemd units have EnvironmentFile= for
> importing environment variables. Even init.d scripts can use `source` with
> the same effect, as can users' own .profile or .foorc scripts... There are
> plenty of nice ways to "share environment variables" without using su.
> 
Users have different shell's and even distributions name them differently
(.profile, .bash_profile). With EnvironmentFile= you force the user to put
the same things at two different places. With su you do not have to
think about all these problems.

Regards,
Holger

> That said, at least try `runuser`...
> 
> On Tue, Nov 22, 2016, 12:07 Benoit SCHMID  wrote:
>   Hello,
> 
>   On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
>   > Don't abuse su for dropping privileges.
> 
>   I agree that using su has drawbacks.
> 
>   But it also have advantages.
>   When you upgrade your db, you upgrade the environment variables.
>   Therefore using su allow you to centralised everything in one
>   place
>   (user settings).
> 
>   This is why, after thinking of the pros and cons, I use su,
>   even if I agree with you, on the fact that should not abuse :-)
> 
>   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
> 
> 
> ___
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.

[Mantas Mikulėnas]

So, uh, that sounded like you value updating one file less (and even mixing
user and daemon configs) above having the service actually work?

Not that it's an excuse anyway. Systemd units have EnvironmentFile= for
importing environment variables. Even init.d scripts can use `source` with
the same effect, as can users' own .profile or .foorc scripts... There are
plenty of nice ways to "share environment variables" without using su.

That said, at least try `runuser`...

On Tue, Nov 22, 2016, 12:07 Benoit SCHMID  wrote:

> Hello,
>
> On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
> > Don't abuse su for dropping privileges.
>
> I agree that using su has drawbacks.
>
> But it also have advantages.
> When you upgrade your db, you upgrade the environment variables.
> Therefore using su allow you to centralised everything in one place
> (user settings).
>
> This is why, after thinking of the pros and cons, I use su,
> even if I agree with you, on the fact that should not abuse :-)
>
> 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
>
___
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.

[Jonathan de Boyne Pollard]

Benoit SCHMID:

 echo -n "Starting Oracle Listener: "
 su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102 
/oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"


Don't abuse su for dropping privileges.

* http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html


It's now 2016, and the first rule for migrating to systemd applies even 
to Oracle softwares.


* http://jdebp.eu./FGA/systemd-house-of-horror/daemonize.html#first-rule

* http://www.server-world.info/en/note?os=CentOS_7=oracle12c=6

* 
https://lists.freedesktop.org/archives/systemd-devel/2014-October/thread.html#24663


* https://www.realdbamagic.com/automatic-db-startup-linux-part-oel-6-7-2/

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

[Benoit SCHMID]

Hello,

On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
> Don't abuse su for dropping privileges. 

I agree that using su has drawbacks.

But it also have advantages.
When you upgrade your db, you upgrade the environment variables.
Therefore using su allow you to centralised everything in one place
(user settings).

This is why, after thinking of the pros and cons, I use su,
even if I agree with you, on the fact that should not abuse :-)

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

[Andrei Borzenkov]

On Tue, Nov 22, 2016 at 11:39 AM, Benoit SCHMID  wrote:
...
> 2. This service starts /etc/rc.d/init.d/sap start.
> % cat /etc/rc.d/init.d/sap
> #!/bin/bash
> ...
> case "$1" in
> start)
> # Oracle listener and instance startup
> echo -n "Starting Oracle Listener: "
> su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102
> /oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"
...
>
> Why is the processed attached to user-.slice instead of sap?

Because "su" opens new session with logind, so everything it does
belongs to this user session. You should really use proper systemd
unit and set User and Group for it instead.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel