-----Original Message----- From: systemd-devel [mailto:[email protected]] On Behalf Of Andrei Borzenkov
> Even in this case behavior is wrong. Currently stopping listener does > not affect existing database connections. Killing all client processes > on listener stop will be rather strong regression. > How ssh does it? It is something similar - master service that need to > spawn multiple independent children. Observe... [root@localhost bin]# systemctl start oracle-orcl.service [root@localhost bin]# systemctl start oracle-listener.service [root@localhost bin]# iptables -I INPUT -p tcp --dport 1521 --syn -j ACCEPT C:\>ver Microsoft Windows [Version 6.1.7601] C:\>sqlplus system@"(description=(address=(protocol=tcp)(host=10.58.17.250)(port=1521))(connect_data=(sid=orcl)))" SQL*Plus: Release 10.2.0.3.0 - Production on Thu Oct 30 12:46:35 2014 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. Enter password: Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> select * from dual; D - X [root@localhost bin]# ps -ef | grep LOCAL oracle 4292 1 0 12:46 ? 00:00:00 oracleorcl (LOCAL=NO) root 4304 2687 0 12:47 pts/1 00:00:00 grep --color=auto LOCAL [root@localhost bin]# systemctl stop oracle-listener.service [root@localhost bin]# ps -ef | grep LOCAL root 4321 2687 0 12:47 pts/1 00:00:00 grep --color=auto LOCAL SQL> select * from dual; select * from dual * ERROR at line 1: ORA-03113: end-of-file on communication channel It would be more sensible if the tnslsnr caused [one of] the oracle background process to fork off a client connection, so the cgroup is correct. This is not the case. I don't think Oracle supports anything running systemd as yet. I can see why. It's a disaster if incorrectly used. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
