Re: SIGTERM?
Hi, I always wanted it done both ways: a) when I need to shutdown **now** (i.e. the UPS is on battery power, only 5 minutes of juice available), I do not want the shutdown to get bogged down or get stuck (I now see el7 report "waiting 60 seconds for the user to logout", thank you very much). so in this case, I do not want any shutdown scripts, just SIGKILL everything, (the out-of-juice UPS will SIGKILL everything the hard way, anyway) b) when I run important databases and applications, I want them to shutdown gracefully without corrupting all their stuff and without requiring manual intervention to restart. Also nice to have the filesystems unmount cleanly and the disks spin down orderly, after flushing all the caches. Somehow I do not think these two desires are compatible with each other. K.O. On Fri, Oct 27, 2017 at 12:57:48PM -0700, ToddAndMargo wrote: > Dear List, > > In the situation I am facing, a database is not shutdown by the > systemd script that started it at boot. (Its start point was > actually hacked into a related bash file called by another > systems script without a shutdown hack.) There is no "ExecStop" > line. NO, IT WAS NO MY DOING !!! > > I am not saying which (proprietary) database as I don’t want to > get into any legal cross hairs. Anyway, someone else is using > the database. The database works fine. > > The vendor is not systemd literate and keeps complaining about > it only works under SysV. And no, they won’t give me the SysV > rc.d scripts and let me convert it for them. And, yes, I know, > you can still use SysV if you must. But, again, as I said, > it is not my doing. > > I am thinking there is a possibility of data corruptions. > > Question: does the general shutdown take care of this issue? > Am I presuming too much to think this is handled by the general > shutdown global SIGTERM? The database does properly respond > to SIGTERM. > > Do I understand the global SIGTERM correctly? > > Many thanks, > -T -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SIGTERM?
On 10/30/2017 06:20 AM, Vladimir Mosgalin wrote: Hi ToddAndMargo! On 2017.10.27 at 16:57:38 -0700, ToddAndMargo wrote next: I was wondering why one would go through all the effort to do a "ExecStop" in systemd if shutdown was going to send SIGTERM to everyone anyway. Well because the process might not have long enough to shutdown before the SIGKILL or have all its sub process complete properly either. There are lots of reasons to have ExecStop (especially for databases). First is handling the case when database can't accept SIGTERM correctly and needs specific command to shutdown instead (e.g. Oracle DB). Second is need to do some pre/post shutdown cleanup, e.g. you want to send some notification to someone else before shutdown. Third is manual picking of process to terminate, systemd can either kill very first process with SIGTERM or kill all, but there are cases when you need to kill something else. For example, this is tree of running processes: (1) wrapper | (2) control manager | (3) child 1 (4) child 2 (5) child 3 systemd can kill either (1) or (1-5) depending on settings, but killing (1) is useless and killing (3-5) directly might harm the service state, the only way to correctly shutdown is to send signal to (2) (or 1 and 2 at once). Here you'll need ExecStop again. I'd say that the only annoyance here is that ExecStop must be synchronous, it must actually wait till everything shutdowns before returning, otherwise systemd will treat it as failed shutdown attempt and kill the service remains right after ExecStop returns. So if you're going to stop by sending SIGTERM to some specific process, you need a wrapper script for ExecStop which waits till everything has shutdown properly. You can't use one that calls shutdown in background and returns without waiting. Anyhow, just like ExecStop allows these kinds of customizations, you can also define "TimeoutStopSec" parameter (e.g. TimeoutStopSec=5min) and systemd will wait that time either after sending SIGTERM (if there is no ExecStop) or after ExecStop and before sending SIGKILL (ExecStop command will be aborted in that case when the time has ran out). Wow! Thank you!
Re: SIGTERM?
Hi ToddAndMargo! On 2017.10.27 at 16:57:38 -0700, ToddAndMargo wrote next: > I was wondering why one would go through all the effort > to do a "ExecStop" in systemd if shutdown was going to send > SIGTERM to everyone anyway. Well because the process might > not have long enough to shutdown before the SIGKILL or have > all its sub process complete properly either. There are lots of reasons to have ExecStop (especially for databases). First is handling the case when database can't accept SIGTERM correctly and needs specific command to shutdown instead (e.g. Oracle DB). Second is need to do some pre/post shutdown cleanup, e.g. you want to send some notification to someone else before shutdown. Third is manual picking of process to terminate, systemd can either kill very first process with SIGTERM or kill all, but there are cases when you need to kill something else. For example, this is tree of running processes: (1) wrapper | (2) control manager | (3) child 1 (4) child 2 (5) child 3 systemd can kill either (1) or (1-5) depending on settings, but killing (1) is useless and killing (3-5) directly might harm the service state, the only way to correctly shutdown is to send signal to (2) (or 1 and 2 at once). Here you'll need ExecStop again. I'd say that the only annoyance here is that ExecStop must be synchronous, it must actually wait till everything shutdowns before returning, otherwise systemd will treat it as failed shutdown attempt and kill the service remains right after ExecStop returns. So if you're going to stop by sending SIGTERM to some specific process, you need a wrapper script for ExecStop which waits till everything has shutdown properly. You can't use one that calls shutdown in background and returns without waiting. Anyhow, just like ExecStop allows these kinds of customizations, you can also define "TimeoutStopSec" parameter (e.g. TimeoutStopSec=5min) and systemd will wait that time either after sending SIGTERM (if there is no ExecStop) or after ExecStop and before sending SIGKILL (ExecStop command will be aborted in that case when the time has ran out). -- Vladimir
Re: SIGTERM?
On Fri, Oct 27, 2017 at 7:57 PM, ToddAndMargo <toddandma...@zoho.com> wrote: >>> On Fri, Oct 27, 2017 at 3:57 PM, ToddAndMargo <toddandma...@zoho.com >>> <mailto:toddandma...@zoho.com>> wrote: >>> >>> Dear List, >>> >>> In the situation I am facing, a database is not shutdown by the >>> systemd script that started it at boot. (Its start point was >>> actually hacked into a related bash file called by another >>> systems script without a shutdown hack.) There is no "ExecStop" >>> line. NO, IT WAS NO MY DOING !!! >>> >>> I am not saying which (proprietary) database as I don’t want to >>> get into any legal cross hairs. Anyway, someone else is using >>> the database. The database works fine. >>> >>> The vendor is not systemd literate and keeps complaining about >>> it only works under SysV. And no, they won’t give me the SysV >>> rc.d scripts and let me convert it for them. And, yes, I know, >>> you can still use SysV if you must. But, again, as I said, >>> it is not my doing. >>> >>> I am thinking there is a possibility of data corruptions. >>> >>> Question: does the general shutdown take care of this issue? >>> Am I presuming too much to think this is handled by the general >>> shutdown global SIGTERM? The database does properly respond >>> to SIGTERM. >>> >>> Do I understand the global SIGTERM correctly? >>> >>> Many thanks, >>> -T >>> >>> > > On 10/27/2017 02:31 PM, Paul Robert Marino wrote: >> >> you understand the global sigterm correctly but there is a problem with >> relying on that. while it is true that a global sigterm is issued it is >> followed shortly afterward by a global kill. what that means is it may not >> give the database sufficient time to shutdown before killing it. whenever >> databases are involved you can not count on the global sigterm to shut it >> down correctly in time >> > > Hi Paul, > > Now I understand. Thank you! > > I was wondering why one would go through all the effort > to do a "ExecStop" in systemd if shutdown was going to send > SIGTERM to everyone anyway. Well because the process might > not have long enough to shutdown before the SIGKILL or have > all its sub process complete properly either. I've run into similar shutdown delay issues with MySQ under systemd, and worse ones with tomcat. (Tomcat init scripts and systemd tools are wrappers for catalina.sh, which is a SysV init script and not a very good one.)
Re: SIGTERM?
On Fri, Oct 27, 2017 at 3:57 PM, ToddAndMargo <toddandma...@zoho.com <mailto:toddandma...@zoho.com>> wrote: Dear List, In the situation I am facing, a database is not shutdown by the systemd script that started it at boot. (Its start point was actually hacked into a related bash file called by another systems script without a shutdown hack.) There is no "ExecStop" line. NO, IT WAS NO MY DOING !!! I am not saying which (proprietary) database as I don’t want to get into any legal cross hairs. Anyway, someone else is using the database. The database works fine. The vendor is not systemd literate and keeps complaining about it only works under SysV. And no, they won’t give me the SysV rc.d scripts and let me convert it for them. And, yes, I know, you can still use SysV if you must. But, again, as I said, it is not my doing. I am thinking there is a possibility of data corruptions. Question: does the general shutdown take care of this issue? Am I presuming too much to think this is handled by the general shutdown global SIGTERM? The database does properly respond to SIGTERM. Do I understand the global SIGTERM correctly? Many thanks, -T On 10/27/2017 02:31 PM, Paul Robert Marino wrote: you understand the global sigterm correctly but there is a problem with relying on that. while it is true that a global sigterm is issued it is followed shortly afterward by a global kill. what that means is it may not give the database sufficient time to shutdown before killing it. whenever databases are involved you can not count on the global sigterm to shut it down correctly in time Hi Paul, Now I understand. Thank you! I was wondering why one would go through all the effort to do a "ExecStop" in systemd if shutdown was going to send SIGTERM to everyone anyway. Well because the process might not have long enough to shutdown before the SIGKILL or have all its sub process complete properly either. -T
Re: SIGTERM?
you understand the global sigterm correctly but there is a problem with relying on that. while it is true that a global sigterm is issued it is followed shortly afterward by a global kill. what that means is it may not give the database sufficient time to shutdown before killing it. whenever databases are involved you can not count on the global sigterm to shut it down correctly in time On Fri, Oct 27, 2017 at 3:57 PM, ToddAndMargo <toddandma...@zoho.com> wrote: > Dear List, > > In the situation I am facing, a database is not shutdown by the > systemd script that started it at boot. (Its start point was > actually hacked into a related bash file called by another > systems script without a shutdown hack.) There is no "ExecStop" > line. NO, IT WAS NO MY DOING !!! > > I am not saying which (proprietary) database as I don’t want to > get into any legal cross hairs. Anyway, someone else is using > the database. The database works fine. > > The vendor is not systemd literate and keeps complaining about > it only works under SysV. And no, they won’t give me the SysV > rc.d scripts and let me convert it for them. And, yes, I know, > you can still use SysV if you must. But, again, as I said, > it is not my doing. > > I am thinking there is a possibility of data corruptions. > > Question: does the general shutdown take care of this issue? > Am I presuming too much to think this is handled by the general > shutdown global SIGTERM? The database does properly respond > to SIGTERM. > > Do I understand the global SIGTERM correctly? > > Many thanks, > -T >
SIGTERM?
Dear List, In the situation I am facing, a database is not shutdown by the systemd script that started it at boot. (Its start point was actually hacked into a related bash file called by another systems script without a shutdown hack.) There is no "ExecStop" line. NO, IT WAS NO MY DOING !!! I am not saying which (proprietary) database as I don’t want to get into any legal cross hairs. Anyway, someone else is using the database. The database works fine. The vendor is not systemd literate and keeps complaining about it only works under SysV. And no, they won’t give me the SysV rc.d scripts and let me convert it for them. And, yes, I know, you can still use SysV if you must. But, again, as I said, it is not my doing. I am thinking there is a possibility of data corruptions. Question: does the general shutdown take care of this issue? Am I presuming too much to think this is handled by the general shutdown global SIGTERM? The database does properly respond to SIGTERM. Do I understand the global SIGTERM correctly? Many thanks, -T
