Re: cron @shutdown
- Reply: Cy Schubert : "Re: cron @shutdown"
- In reply to: Cy Schubert : "Re: cron @shutdown"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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,