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

[Mantas Mikulėnas]

On Tue, Oct 2, 2018 at 9:25 PM Andrei Borzenkov <arvidjaar at gmail.com> wrote:

> 02.10.2018 19:52, Mantas Mikulėnas пишет:
> > On Tue, Oct 2, 2018 at 4:44 PM Thomas Blume <Thomas.Blume at suse.com>
> wrote:
> >
> >> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20181003/7465ace0/attachment.html>