Hello! Risto, Thanks for the you tips, the problem was solved. For systemd in service settings added “KillMode=process”, this makes it possible to kill only the basic process and does not affect the child processes.
$ cat /lib/systemd/system/sec@.service [Unit] Description=Simple Event Correlator (instance %I) After=syslog.target [Service] Type=forking PIDFile=/run/sec-%I.pid ExecStart=/usr/bin/sec -detach -pid=/run/sec-%I.pid -conf=/etc/sec/%I.sec --dump=/tmp/sec-tomcat.dump --nochildterm -log=/var/log/sec-%I --intevents $OPTIONS_%I EnvironmentFile=/etc/sysconfig/sec KillMode=process [Install] WantedBy=multi-user.target -- WBR Yuri Kazankin yuni...@yahoo.com > On 2 авг. 2016 г., at 0:53, Risto Vaarandi <risto.vaara...@gmail.com> wrote: > > hi Yuri, > if your platform is Linux, you can figure out the parent process ID by > running "ps -ef" and inspecting the third column. This command lists all > processes on your system, so you would probably need to grep the output for > relevant processes (e.g., ps -ef | grep tomcat). When you shut down sec, > please also inspect its log, because sec reports the ID of every process it > sends the TERM signal. The relevant sec log messages look like follows: > SIGTERM received: shutting down SEC > Sending SIGTERM to process 20879 > > Nevertheless, after having a look into the scripts, I have some doubts if the > application is running as sec child process, since from the shell process > that runs restart-tomcat.sh you are invoking startup.sh which creates another > process (that process should become a grandchild of sec which no longer gets > SIGTERM). Since you are experiencing this problem when using systemctl > command for restarting sec, maybe this issue is related to how systemd shuts > down a service. After browsing a web, I run into couple of threads that > describe a similar scenario, for example: > http://stackoverflow.com/questions/32208782/cant-detach-child-process-when-main-process-is-started-from-systemd > > <http://stackoverflow.com/questions/32208782/cant-detach-child-process-when-main-process-is-started-from-systemd> > > > In order to find out if you are experiencing a similar problem, you could try > stopping sec in two ways -- first by shutting it down manually by sending > TERM signal to sec process, and then stopping it with 'systemctl stop > sec@tomcat'. If your application stays alive in the first case but dies in > the second case, it has to be systemd which stops your application alongside > with sec, probably because your application was started by sec and belongs to > the same process group. Nevertheless, if systemd uses the TERM signal for > taking down your application, you could still use the trap '' 15 statement in > the restart-tomcat.sh script for ignoring this signal. However, I would > recommend to create systemd service files for your application, so that you > could start and stop it with systemctl. Invoking "systemctl restart ..." > instead of restart-tomcat.sh would probably solve the problem, since systemd > is made aware that your application is a separate service. > > kind regards, > risto > > 2016-08-01 14:14 GMT+03:00 Yuri Kazankin <yuni...@yahoo.com > <mailto:yuni...@yahoo.com>>: > Hi Risto, > > Sec process is seen as: > /usr/bin/perl -w /usr/bin/sec -detach -pid=/run/sec-tomcat.pid > -conf=/etc/sec/tomcat.sec --debug=6 --dump=/tmp/sec-tomcat.dump --nochildterm > -log=/var/log/sec-tomcat --nointevents -input=/var/log/tomcat/catalina.out > > Unfortunately, --nochildterm option does not fix the problem. I cannot find > the dump file, I tried to specify it in the start script > (--dump=/tmp/sec-tomcat.dump), but without result. > > The command "ps wuaxf" does not reveal how the child process: > # ps wuaxf > root 31114 0.1 0.2 150232 9724 ? S 13:42 0:01 > /usr/bin/perl -w /usr/bin/sec -detach -pid=/run/sec-tomcat.pid > -conf=/etc/sec/tomcat.sec --debug=6 --dump=/tmp/sec-tomcat.dump --nochildterm > - > root 31214 4.8 6.8 3756928 266000 ? Sl 13:44 0:39 > /opt/java-8-sun/jre/bin/java > -Djava.util.logging.config.file=/opt/tomcat-7.0.55/conf/logging.properties > -Djava.util.logging.manager=org.apache > > In my restart-tomcat.sh: > kill -9 `cat /run/tomcat-7.0.55.pid` ; sleep 5 ; > /opt/tomcat-7.0.55/bin/startup.sh > > In the attachment native scripts of Apache Tomcat: startup.sh and catalina.sh > > Trap will try if nothing else helps. > > Can you something else advise? > > > > > > -- > WBR > Yuri Kazankin > yuni...@yahoo.com <mailto:yuni...@yahoo.com> >> On 31 июля 2016 г., at 22:23, Risto Vaarandi <risto.vaara...@gmail.com >> <mailto:risto.vaara...@gmail.com>> wrote: >> >> hi Yuri, >> my apologies for not answering earlier -- your e-mail landed in my spam >> folder initially :( >> >> I am suspecting that your application is started in a way which makes it a >> child process of sec. However, when sec shuts down, it sends the TERM signal >> to all its child processes by default. If the shell process that is >> executing the content of /opt/scripts/restart-tomcat.sh is still running, >> this process will get the TERM signal as well. Therefore, if the application >> was started with the shell 'exec' directive that replaces the shell process >> with the application process, it is actually your application which gets the >> TERM signal. >> >> In order to find out whether your application is running as a child process >> of sec, send the USR1 signal to the sec process which creates the dump file >> (by default located at /tmp/sec.dump). This file contains detailed >> information about internal state of sec, and also provides a list of all >> child processes. >> >> If your application is indeed stopping because of the TERM signal from sec, >> there are couple of workarounds: >> 1) start sec with the --nochildterm command line option which disables >> sending TERM to child processes, >> 2) include a 'trap' statement in /opt/scripts/restart-tomcat.sh that would >> ignore the TERM signal (e.g., trap '' 15) >> >> Also, if your application is terminating for other reasons than TERM signal >> from sec, can you share the content of /opt/scripts/restart-tomcat.sh? >> >> Hope this helps, >> risto >> >> >> >> 2016-07-29 13:55 GMT+03:00 Yuri Kazankin <yuni...@yahoo.com >> <mailto:yuni...@yahoo.com>>: >> Hello! >> >> I have a problem with sec 2.7.10 >> >> I created the instance: >> # cat /etc/sysconfig/sec >> OPTIONS_tomcat="-input=/var/log/tomcat/catalina.out” >> >> >> and configured via systemd >> # cat /lib/systemd/system/sec@.service >> [Unit] >> Description=Simple Event Correlator (instance %I) >> After=syslog.target >> >> [Service] >> Type=forking >> PIDFile=/run/sec-%I.pid >> ExecStart=/usr/bin/sec -detach -pid=/run/sec-%I.pid -conf=/etc/sec/%I.sec >> --debug=6 --nochildterm -log=/var/log/sec-%I --nointevents $OPTIONS_%I >> EnvironmentFile=/etc/sysconfig/sec >> >> [Install] >> WantedBy=multi-user.target >> >> >> My rules restart the application after the event in the log: >> # cat /etc/sec/tomcat.sec >> type=SingleWithSuppress >> ptype=RegExp >> pattern=(^.+OutOfMemoryError.+$) >> desc=Tomcat restarted after OutOfMemoryError Exception >> action=shellcmd /opt/scripts/restart-tomcat.sh >> window=300 >> >> And it works great! But after the event, if I try to execute a restart of >> the instance (systemctl restart sec@tomcat), my application stops((( >> I can not understand why this is happening and how to fix it ... >> >> >> -- >> WBR >> Yuri Kazankin >> yuni...@yahoo.com <mailto:yuni...@yahoo.com> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Simple-evcorr-users mailing list >> Simple-evcorr-users@lists.sourceforge.net >> <mailto:Simple-evcorr-users@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> <https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users> >> > > >
------------------------------------------------------------------------------
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
