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
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
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
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
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
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
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
Lennart Poettering, Red Hat