Re: cron @shutdown

From: Xin Li <delphij_at_delphij.net>
Date: Wed, 03 Aug 2022 05:37:36 UTC

On 8/2/22 08:02, Cy Schubert wrote:
> In message <CANCZdfo9JZzH8GkA+d1ddi6cATfbN1e0+5_j3ALDpmgT63EYDQ@mail.gmail.c
> om>
> , Warner Losh writes:
>> --000000000000543e5405e5435396
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Tue, Aug 2, 2022, 8:54 AM Cy Schubert <Cy.Schubert@cschubert.com> 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.

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.

Cheers,