On 10/15/13 01:58, Nick Hibma wrote: >> Indeed... the way my patch currently does things, it looks for the >> firstboot sentinel at the start of /etc/rc, which means it *has* to >> be on /. Making the path an rcvar is a good idea (updated patch >> attached) but we still need some way to re-probe for that file after >> mounting extra filesystems. > > In many cases a simple > > test -f /firstboot && bla_enable='YES' || bla_enable='NO' > rm -f /firstboot > > in your specific rc.d script would suffice. [...] > I am not quite sure why we need /firstboot handling in /etc/rc. Your suggestion wouldn't work if you have several scripts doing it; the first one would remove the sentinel and the others wouldn't run. In my EC2 code I have a single script which runs after all the others and removes the sentinel file, but that still means that every script has to be executed on every boot (even if just to check if it should do anything); putting the logic into /etc/rc would allow rcorder to skip those scripts entirely. > Perhaps it is a better idea to make this more generic, to move the rc.d script containing a 'runonce' keyword to a subdirectory as the last step in rc (or make that an rc.d script in itself!). That way you could consider moving it back if you need to re-run it. Or have an rc.d script setup something like a database after installing a package by creating a rc.d runonce script. > > Default dir could be ./run-once relative to the rc.d dir it is in, configurable through runonce_directory . > > Note: The move would need to be done at the very end of rc.d to prevent rcorder returning a different ordering and skipping scripts because of that. I considered this, but decided that the most common requirement use of "run once" would be for "run when the system is first booted", and it would be much simpler to provide just the firstboot functionality. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoidReceived on Tue Oct 15 2013 - 18:57:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:43 UTC