Nils Philippsen <nphilipp(a)redhat.com> writes:
1. process 1 (p1) prepares the service
2. when finished, p1 forks p2 which will be the long-runner, controlling
any eventual children
3. p1 exits
This seems to be a standard procedure for self-detaching daemons to
me.
That's the old forking-daemon way. Most modern initsystems work best
with non-forking daemons.
I've often had to chain multiple of these to get the desired
results --
but that's more a matter of convenience (perhaps my bash is just too
rusty and it can be done more elegantly). What matters more to me (this
came to mind only yesterday while driving home) is that if you do:
cat $somefile | while read line; do ... done
variables set in the while loop have no effect outside of it, or if you
this effect is known and this example can be written as
| while read line ... done < $somefile
But we are speaking about preparation scripts of daemons. Do you really
need such tasks there?
except OSError, e:
# clean up OS error
...
except SomeException, e:
# do something else
sys.stderr.print "Warning: doing foo failed, continuing (%s)" % str (e)
except:
# panic!
sys.stderr.print "Error: %s" % str(e)
sys.exit (42)
I don't know if any of this is necessary for init code, but these are
some things that I miss or find cumbersome in shell.
I do not say that shell shall be used for everything. I just say that
python is not an option for any part of sysinit which should be written
completely in C. (ba)sh plus usual POSIX/GNU tools are the optimal
choice for preparation tasks, but these are no deps of the sysinit
system itself but of the specific daemon.
Enrico