[systemd-devel] starting Oracle with systemd

Fisher, Charles J. (Top Echelon) Charles.Fisher at alcoa.com
Thu Oct 30 12:29:17 PDT 2014


-----Original Message-----
From: Lennart Poettering [mailto:lennart at 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 at localhost system]# psc | grep lsnr
8619 oracle   1:name=systemd:/system.slic /home/oracle/Ora12c/db/bin/tnslsnr LISTENER -inherit

[root at 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.


More information about the systemd-devel mailing list