Re: cron @shutdown

On Tue, 2 Aug 2022 22:37:36 -0700
Xin Li <[email protected]> wrote:

> On 8/2/22 08:02, Cy Schubert wrote:
> > In message <[email protected]  
> > om>  
> > , Warner Losh writes:  
> >> --000000000000543e5405e5435396
> >> Content-Type: text/plain; charset="UTF-8"
> >>
> >> On Tue, Aug 2, 2022, 8:54 AM Cy Schubert <[email protected]> wrote:
> >>  
> >>> Hi,
> >>>
> >>> Does anyone think there might be some utility with an @shutdown crontab(5)
> >>> "nickname" similar to @reboot but instead when cron shuts down?
> >>>
> >>> I pointed out to one of my customers that @reboot might be an option
> >>> instead of an rc script (or in his case a systemd unit file). Not that an
> >>> @reboot for FreeBSD cron would contribute to solving his Linux problem but
> >>> might our users be interested in something like this?
> >>>  
> >>
> >>
> >> If it's simple and increases portability, I'm all for it.  
> > 
> > It's simple but there's no Linux equivalent, yet. My thoughts are to
> > implement in FreeBSD then canvas then submit a pull request to the Linux
> > Vixie Cron maintainer and discuss with the various Linux vendors.  
> 
> I think it would be worth updating our cron with OpenBSD's cron(8) or a 
> newer vixie-cron version first.  There are a lot of improvements that 
> would be useful for us too.

We could look at OpenBSD's cron but the Vixie-cron, as installed on Red
Hat, is IMO a regression as it doesn't implement some of the
"nicknames" we already support.

> 
> Regarding @shutdown, I'd second Warner that if it's simple to implement, 
> we should have it.  However, we should also keep in mind that delaying 
> shutdown can be bad as eventually the shutdown process would send 
> SIGKILL to everyone, and the timer starts before cron receives SIGTERM. 
>   So the user *might* want their software to be more robust with crashes 
> and developers should focus more on how to make the software to recover 
> quickly from a crash, because crash can not be avoided: hardware issue, 
> user sending SIGKILL, bugs, etc. can all cause it to crash. On the other 
> hand, making too much effort with how to "properly" shutdown generally 
> makes the situation worse, and sometimes they don't contribute to a 
> better stop-to-start-and-ready-to-use time compared to a 
> crash-only-with-fast-recovery design, so while it can be really useful 
> for some scenarios, it's probably not the best thing that the user 
> should do.

This makes my suggestion regressive as there is a greater chance an
end-user script would exceed the ninety second timeout.

-- 
Cheers,
Cy Schubert <[email protected]>
FreeBSD UNIX:  <[email protected]>   Web:  http://www.FreeBSD.org
NTP:           <[email protected]>    Web:  https://nwtime.org

			e**(i*pi)+1=0