-----Original Message----- From: Lennart Poettering [mailto:lenn...@poettering.net]
> "If you run those instances in separate cgroups"? what's that supposed > to mean? We do not expose cgroups as concept in systemd. Are you > accessing cgroupfs directly? > I have no idea how Oracle works, and the above it too cryptic to fully > understand what point you are trying to make. Can you eloborate on > this for somebody who doesn't know a thing about Oracle? And please > don't paste tons of Oracle outputs here, they don't help, they make > everything more cryptic and unintelligible... ...and I am rather weak on all the new systemd concepts. No, whatever cgroupfs is, I'm not using it. I think. Summary: systemd kills Oracle sessions, with severe prejudice, when a listener and instance(s) are started as separate services. This appears to be the key: ---------------------- [root@localhost system]# psc | grep lsnr 8619 oracle 1:name=systemd:/system.slic /home/oracle/Ora12c/db/bin/tnslsnr LISTENER -inherit [root@localhost system]# ps xawf -eo args,cgroup | tail ... ora_q002_orcl 1:name=systemd:/system.slice/oracle-orcl.service ora_q003_orcl 1:name=systemd:/system.slice/oracle-orcl.service oracleorcl (LOCAL=NO) 1:name=systemd:/system.slice/oracle-listener.service ora_j000_orcl 1:name=systemd:/system.slice/oracle-orcl.service ora_j001_orcl 1:name=systemd:/system.slice/oracle-orcl.service ---------------------- For the instance ORCL, the remote connections (LOCAL=NO) have the "cgroup" column above from the **LISTENER** (which is not associated with a specific instance), not from the background processes of the target instance in question. When I stop the listener, systemd kills *all* of the LOCAL=NO processes, for all instances. It is common for a single listener to spawn connections for multiple installations, versions, and instances. THEY ALL DIE when systemd goes on a listener stop rampage. If/when I install a new version of Oracle and configure the latest listener to serve all my past installed instances, I will have a machine outage in moving the listener, rather than a short period where new connections are rejected (while existing sessions are unmolested). This is not the fault of systemd. The tnslsnr process above is forking, not a background process. There is no reasonable way for system software to track this. I hope Oracle fixes this with the next release. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
