[systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mantas Mikulėnas]

On Tue, Dec 8, 2015 at 5:04 AM, <niksa at jurinovic.com> wrote:

> On Monday, December 07, 2015 11:28:54 PM you wrote:
>
> > It might be clearer if you described how exactly the daemon is started
> and
>
> > which cgroup it runs under (according to systemd-cgls). Perhaps you're
>
> > starting it directly from the shell, and not via systemctl as intended?
>
> >
>
>
>
> Oracle (database and listener) is started in two different ways:
>
>
>
> 1. Via root console executing the command:
>
>
>
> # su - oracle -l -c '${ORACLE_HOME}/bin/dbstart'
>
>
>
> If Oracle is started in this way, the processes 'systemd (oracle)' and
> '(sd-pam) (oracle)' DO NOT appear. And that's the problem. Seems that
> oracle daemon cannot live without these processes and it dies (shutdown by
> itself) very soon (after 5-15 minutes working). The lack of these processes
> is the cause of the crash here.
>
>
>
> 2. By logging in directly as 'oracle' user to console (tty). In this case
> the processes 'systemd (oracle)' and '(sd-pam) (oracle)' appear immediately
> after logging to console. The database and listener is then started
> executing 'dbstart' from console. This way Oracle never crashes, except if
> I deliberately kill the two processes as root during the session and Oracle
> crashes immediately.
>

I see. This doesn't kill Oracle by itself, however, it still can cause
various other problems. You really should launch daemons through a systemd
.service, Oracle is no exception.

> The "systemd --user" process is meant for interactive users (as in, not
>
> > system accounts) – it acts as the user's personal service manager. I
> don't
>
> > think lack of that process is the cause here, maybe an effect instead –
>
> > killing it is part of logind's cleanup when a user logs out.
>
>
>
> No, the lack of these processes is the cause of the crash, as I already
> said above. So far as these processes are running, no fear of Oracle's
> crash.
>

Correlation does not imply causation. These processes do nothing relevant
by themselves; their presence only indicates that a systemd-logind _user
session_ exists, which is the cause.

> What uid does "oracle" have – is it within the system account range
>
> > (usually 1–999) or user account (1000–)? I wonder if it's the latter,
> which
>
> > would mean systemd-logind would clean up various things like IPC on
>
> > logout... (see logind.conf)
>
>
>
> [root at proton ~]# id oracle
>
> uid=54321(oracle) gid=54321(oinstall)
> groups=54321(oinstall),54322(dba),54323(oper),54324(backupdba),54325(dgdba),54326(kmdba),54327(asmdba)
>

Ok, so the UID is the problem. (These look suspiciously like made-up
numbers, but I'm guessing they are centrally-managed accounts, maybe NIS or
LDAP.)

So, since "oracle" has an UID ≥ 1000, and since you probably cannot change
that, you should instead *disable RemoveIPC= in /etc/systemd/logind.conf*
to disable the automatic IPC cleanup.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20151208/50a3a9ed/attachment.html>