Discussion:
specialized user sessions for running large processes
(too old to reply)
Thomas Blume
2018-10-02 13:32:40 UTC
Permalink
Hi,

there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.

At system boot, they get started via a user session and inherit the
restrictions from the user slice.
That is not really appropriate for such large processes as they usually
need higher resource limits than normal users.
Hence, they should get rather attached below the system slice (or a
dedicated custom slice below -.slice)
Also, those specialized users, don't need a full blown user session but
only that much environment which is necessary for doing their management
tasks.
Unfortunately, pam_systemd enforces all users to get attached below the
user.slice at login.

So, what I need would be the possibility to put a user outside the user
slice and/or start a customized session instead of a normal user
session.

I'm looking for the best approach to get this.
Would a patch to pam_systemd, that allows the setup of such specialized
user sessions be acceptable?
If not, are there any other ideas to get this?

Thanks and regards
Thomas
Lennart Poettering
2018-10-02 14:17:14 UTC
Permalink
Post by Thomas Blume
Hi,
there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.
At system boot, they get started via a user session and inherit the
restrictions from the user slice.
That is not really appropriate for such large processes as they usually
need higher resource limits than normal users.
Hence, they should get rather attached below the system slice (or a
dedicated custom slice below -.slice) Also, those specialized users, don't
need a full blown user session but
only that much environment which is necessary for doing their management
tasks.
Unfortunately, pam_systemd enforces all users to get attached below the
user.slice at login.
So, what I need would be the possibility to put a user outside the user
slice and/or start a customized session instead of a normal user
session.
I'm looking for the best approach to get this.
Would a patch to pam_systemd, that allows the setup of such specialized
user sessions be acceptable?
If not, are there any other ideas to get this?
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between system and regular
users). Moreover system services should really be started as system
servers, and not from login sessions...

Lennart
--
Lennart Poettering, Red Hat
Thomas Blume
2018-10-02 14:44:17 UTC
Permalink
Post by Lennart Poettering
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between system and regular
users).
Sure, but even UID 0 would be still amongst the user.slice and get the
user restrictions, right?
Post by Lennart Poettering
Moreover system services should really be started as system
servers, and not from login sessions...
Yes, normally they should be started that way, but what if you need to
do some maintenance tasks, for example starting a database in a special
mode?

Regards
Thomas
Lennart Poettering
2018-10-02 15:27:49 UTC
Permalink
Post by Thomas Blume
Post by Lennart Poettering
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between system and regular
users).
Sure, but even UID 0 would be still amongst the user.slice and get the
user restrictions, right?
well, yes.

I mean not sure what you are asking for. *every* userspace process in
systemd needs to be managed under a unit. The cgroup tree is
universal, you cannot have processes outside of it, thus you have to
pick a unit.

Hence, yes, if you start some code as part of a user session it's part
of the user session units. If you start some code as a system service
then it is part of the service unit. What else would you expect? It
needs to be part of something.
Post by Thomas Blume
Post by Lennart Poettering
Moreover system services should really be started as system
servers, and not from login sessions...
Yes, normally they should be started that way, but what if you need to
do some maintenance tasks, for example starting a database in a special
mode?
I don't understand what you are asking.

What would you like to happen? if you start a process from such a
pseudo session, what unit would you want it to be assigned to?

Lennart
--
Lennart Poettering, Red Hat
Thomas Blume
2018-10-03 09:29:02 UTC
Permalink
Post by Lennart Poettering
Post by Thomas Blume
Post by Lennart Poettering
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between system and regular
users).
Sure, but even UID 0 would be still amongst the user.slice and get the
user restrictions, right?
well, yes.
I mean not sure what you are asking for. *every* userspace process in
systemd needs to be managed under a unit. The cgroup tree is
universal, you cannot have processes outside of it, thus you have to
pick a unit.
Hence, yes, if you start some code as part of a user session it's part
of the user session units. If you start some code as a system service
then it is part of the service unit. What else would you expect? It
needs to be part of something.
AFAICS only the root slice is universal and contains the user and system
slice.
For the purpose of SAP, it would be good to have a separate custom slice
where the special resource demands of SAP can be addressed.
Also, when starting SAP in the user slice the SAP processes get killed
at shutdown as soon as the user sessions get stopped.
But thats too early for a system-like process like SAP.
When starting SAP in the system slice this issue doesn't happen, but
there seems to be no possibility to do management tasks for SAP with the
same environment and resource limits like when it was started.
Post by Lennart Poettering
Post by Thomas Blume
Post by Lennart Poettering
Moreover system services should really be started as system
servers, and not from login sessions...
SAP is not a normal non-interactive daemon.
There are some management tasks that need to be executed via the
dedicated SAP user that Andrej described.
And it should be possible to manage SAP via this SAP user with
dedicated SAP resource limits and not with the normal user resource
limits.
But that isn't possible if the SAP user gets ordered below the user
slice like normal users.
Post by Lennart Poettering
Post by Thomas Blume
Yes, normally they should be started that way, but what if you need to
do some maintenance tasks, for example starting a database in a special
mode?
I don't understand what you are asking.
What would you like to happen? if you start a process from such a
pseudo session, what unit would you want it to be assigned to?
A dedicated SAP unit under a dedicated SAP slice would be the best.
This unit should contain the User= parameter and take care of the
start of SAP at system boot.
Is it possible that, when loggin in as the same user as specified in the
User= parameter, the user gets assigned to the dedicated SAP unit?

I understand that this request is an unusal demand for systemd, but if
the system is supposed to be a proper platform for SAP that needs to be
addressed somehow.
If thats not possible, is there a way to take a user completely out of
systemd management?


Thanks and regards
Thomas
Lennart Poettering
2018-10-05 18:19:43 UTC
Permalink
Post by Thomas Blume
Post by Lennart Poettering
I mean not sure what you are asking for. *every* userspace process in
systemd needs to be managed under a unit. The cgroup tree is
universal, you cannot have processes outside of it, thus you have to
pick a unit.
Hence, yes, if you start some code as part of a user session it's part
of the user session units. If you start some code as a system service
then it is part of the service unit. What else would you expect? It
needs to be part of something.
AFAICS only the root slice is universal and contains the user and system
slice.
For the purpose of SAP, it would be good to have a separate custom slice
where the special resource demands of SAP can be addressed.
Well, you do get a custom slice, it's called "user-XYZ.slice", just
for sessions of that user, where XYZ is the UID of your user that you
run SAP as.

But no, systemd knows no concept of "interactive logins that are
actually system services", and I am not sure we should add that.

There was a plan to allow per-user configuration which slice to assign
user scopes and ***@.service instances to. But this has not been
implemented, and is kinda stalled because Linux has no sensible and
accepted concept of extending the user database with additional
information like that. i.e. if the slice assignment for a user's units
shall be configurable, then this should be done in the user database,
but the Linux user database is famously non extensible.
Post by Thomas Blume
Also, when starting SAP in the user slice the SAP processes get killed
at shutdown as soon as the user sessions get stopped.
But thats too early for a system-like process like SAP.
When starting SAP in the system slice this issue doesn't happen, but
there seems to be no possibility to do management tasks for SAP with the
same environment and resource limits like when it was started.
I know that some folks turn off KillUserProcesses= in logind.conf for
stuff such as SAP. But of course, SAP really really shouldn#t work
that way... and turning that off is a frickin' hack.
Post by Thomas Blume
Post by Lennart Poettering
Post by Thomas Blume
Post by Lennart Poettering
Moreover system services should really be started as system
servers, and not from login sessions...
SAP is not a normal non-interactive daemon.
There are some management tasks that need to be executed via the
dedicated SAP user that Andrej described.
And it should be possible to manage SAP via this SAP user with
dedicated SAP resource limits and not with the normal user resource
limits.
But that isn't possible if the SAP user gets ordered below the user
slice like normal users.
Well, you can't have it both ways. Either it's a login user or a
system service, systemd does not have a third concept, and quite
frankly instead of adjusting systemd to add that it appears to me that
SAP should really be fixed instead to work like any other system
service.
Post by Thomas Blume
Post by Lennart Poettering
Post by Thomas Blume
Yes, normally they should be started that way, but what if you need to
do some maintenance tasks, for example starting a database in a special
mode?
I don't understand what you are asking.
What would you like to happen? if you start a process from such a
pseudo session, what unit would you want it to be assigned to?
A dedicated SAP unit under a dedicated SAP slice would be the best.
Then make it a proper system service. If SAP insists on being spawned from a
login shell, it might be possible to make it work by using "bash
--login" in the ExecStart= line. if it also requires an interactive
pty, then it might be possible to invoke it through screen in
ExecStart=... But of course that is always going to be hacky...

Another option might be to use systemd-run --pty or so from a terminal
login. That allows you to start someting intractively but still as
system service...
Post by Thomas Blume
This unit should contain the User= parameter and take care of the
start of SAP at system boot.
Is it possible that, when loggin in as the same user as specified in the
User= parameter, the user gets assigned to the dedicated SAP unit?
I understand that this request is an unusal demand for systemd, but if
the system is supposed to be a proper platform for SAP that needs to be
addressed somehow. If thats not possible, is there a way to take a user
completely out of
systemd management?
No. If you turn off pam_systemd, then SAP would run as part of
sshd.service or whatever you start it from, which is going to make it
worse...

Lennart
--
Lennart Poettering, Red Hat
Mantas Mikulėnas
2018-10-02 16:52:13 UTC
Permalink
Post by Thomas Blume
Hi,
there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.
What exactly do you mean by "via special users", and why is that? Anything
that a "special user" can start, a .service unit can start directly too.
(Perhaps not the nicest-looking .service unit, but that is besides the
point.)

I am nowhere near being an Oracle database/anything admin, but we do have a
server successfully starting Oracle 11 XE via systemd and there haven't
been any problems with it for over two years. The only really special
config it needs is "RemoveIPC=no" in logind.conf...
--
Mantas Mikulėnas
Andrei Borzenkov
2018-10-02 18:24:59 UTC
Permalink
Post by Mantas Mikulėnas
Post by Thomas Blume
Hi,
there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.
What exactly do you mean by "via special users", and why is that? Anything
that a "special user" can start, a .service unit can start directly too.
(Perhaps not the nicest-looking .service unit, but that is besides the
point.)
SAP installation is done under dedicated (normally non-system) user; a
lot of configuration is defined in ~/.profile (or ~/.login depending on
user shell) and similar shell startup files; without sourcing these
files it is basically impossible to get working environment. So
traditionally SAP processes were started by "su - sidadm -c startsap" or
similar - the main objective is having login shell that sources startup
files.

Please do not start telling that it can be done differently. Until SAP
implements *SUPPORTED* different solution (startup files are maintained
by SAP installer automatically among other things) using login shell is
the only supported way to use SAP.

It may be possible to use something like "sh -l -c ..." but it still
must be explicitly supported by vendor. I do not know if SAP supports this.
Post by Mantas Mikulėnas
I am nowhere near being an Oracle database/anything admin, but we do have a
server successfully starting Oracle 11 XE via systemd and there haven't
been any problems with it for over two years. The only really special
config it needs is "RemoveIPC=no" in logind.conf...
Oracle is just one of many databases that can be used by SAP and there
are application servers and a lot of other components.
Mike Gilbert
2018-10-03 04:54:37 UTC
Permalink
Post by Andrei Borzenkov
Please do not start telling that it can be done differently. Until SAP
implements *SUPPORTED* different solution (startup files are maintained
by SAP installer automatically among other things) using login shell is
the only supported way to use SAP.
This is just not the way system services work with systemd.

If you want a supported solution from SAP, perhaps you should contact SAP.
Mantas Mikulėnas
2018-10-03 05:53:27 UTC
Permalink
Post by Mantas Mikulėnas
Post by Mantas Mikulėnas
Post by Thomas Blume
Hi,
there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.
What exactly do you mean by "via special users", and why is that?
Anything
Post by Mantas Mikulėnas
that a "special user" can start, a .service unit can start directly too.
(Perhaps not the nicest-looking .service unit, but that is besides the
point.)
SAP installation is done under dedicated (normally non-system) user; a
lot of configuration is defined in ~/.profile (or ~/.login depending on
user shell) and similar shell startup files; without sourcing these
files it is basically impossible to get working environment. So
traditionally SAP processes were started by "su - sidadm -c startsap" or
similar - the main objective is having login shell that sources startup
files.
Please do not start telling that it can be done differently. Until SAP
implements *SUPPORTED* different solution (startup files are maintained
by SAP installer automatically among other things) using login shell is
the only supported way to use SAP.
It may be possible to use something like "sh -l -c ..." but it still
must be explicitly supported by vendor. I do not know if SAP supports this.
If the main objective is having a login shell, then it sounds that all
methods of obtaining that should be equally supported. Explicit 'sh -l'
starts a login shell perfectly well and actually seems more reliable than
relying on 'su' to start one.

So, sure, you can do ExecStart=/bin/sh -l -c "..." or even manually source
those startup files from within the -c. Hopefully they didn't say they need
an *interactive* login shell, do they?

If 'su' is strictly required, you could even use ExecStart=/bin/su if you
made sure that the su PAM stack skips pam_systemd in this situation.
--
Mantas Mikulėnas
Continue reading on narkive:
Loading...