Re: specialized user sessions for running large processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 2, 2018 at 9:25 PM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:
02.10.2018 19:52, Mantas Mikulėnas пишет:
> On Tue, Oct 2, 2018 at 4:44 PM Thomas Blume <Thomas.Blume@xxxxxxxx> 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
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux