Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal <jh...@dataix.net>:
On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote:
Hi,
On 2011-11-25 08:02, Jason Hellenthal wrote:
> So with that said... is there a way we could actually make this run
@reboot only ?
Debian's cron[0] and Fedora's cronie[1] have solved this by touching a
file on first startup and running @reboot only when this file does not
yet exist.
Note that while [0] may point to other patches that might be of interest
to FreeBSD, they are still WIP (as evident from the linked patch) as we
are still in the process of quiltifying our current code base.
While this sounds like a perfectly sane way to handle the problem at
hand this also introduces a need to write some cleanup code to take care
of the file semantics. I think comparing daemon start times to the time
a system was booted or similiar would alleviate the need for all that.
Maybe a flag for @reboot "-s <seconds>" seconds after boottime to allow
running @reboot jobs. And set the default to 3600 seconds. At least this
would allow adjustment for those startup processes that may take some
considerable time before multiuser mode is entered.
Just some thought.
I really don't think we need to go the route of using files to store
information when there is enough information available already via
syscall's.
If system startup were to be unusually delayed (dhcp or nfs trouble eg),
$time_period might have passed when cron starts, so there would have to be
some notifying mechanism for @reboot jobs not being run, and operator
action would be required.
One could "cron restart" within $time_period and run @reboot twice.
I don't like this idea.
In my bikeshed, @reboot should be called @cronstart, but it shouldn't
because of uniformity across OSs.
The cron manpage should reflect the actual behaviour (already patched in
svn),
and all "definitely only on boot"-scripts should go in local/etc/rc.d.
Michael
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
