[systemd-devel] specialized user sessions for running large processes

[Lennart Poettering]

On Mi, 03.10.18 11:29, Thomas Blume (Thomas.Blume at suse.com) wrote:

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

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

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

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

> 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