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