On Mon, 2008-01-07 at 19:27 +0100, Enrico Scholz wrote:
> Nils Philippsen <nphilipp@xxxxxxxxxx> writes:
[...]
> sorry, but a design like
>
> parent
> |-- child0
> `- child1
>
> where signals must be sent to child0 to control parent + child1 smells
> somehow broken.
I was more thinking along the lines of:
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.
The caller can't know or even reliably guess the pid of p2.
> >> > To make the init process robust, services should check their
> >> > prerequisites before starting, or even ensure that they are met
> >> > (e.g. /etc/init.d/sshd generating host keys).
> >>
> >> Question is where to draw the line. E.g. do you make 'rpm -V postgresql'
> >> to verify that program is not corrupted?
> >
> > You know what I mean
>
> no
You're intentionally ignoring what I mean. I could throw around terms
like "common sense", but there's a lot of dissent about what that
means ;-).
> >> Resulting scripts will be much longer. E.g. how much lines of python
> >> code are required for
> >>
> >> | sed '/^foo/s!/bin!/opt!' file | tac
> >
> > Where would you find such a line in an init script?
>
> Does it look so uncommon? 'sed' is used very often, pipes too. 'tac'
> can be there too, e.g. with a trailing 'sed "1p;d"'
I can think of easier ways to extract the last line (if I'm reading your
sed correctly ;-).
> >> What are you missing specifically?
> >
> > Powerful string ops come to mind,
>
> which string ops other than ${..##..} + ${..%%..} do you need in
> initscripts?
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
want them to have effect, you have to do nasty things (or my bash is
rusty again ;-).
> > built-in regular expressions or
>
> where do you need regexps in initscripts?
To (more) easily extract certain part of strings for example, instead of
using multiple removal of heading and trailing characters. To find out
whether a line matches a certain pattern, think of your "sed
'/^foo/...'" construct above.
> > exceptions
>
> set -e
Throwing exceptions is one thing, but you should be able to catch them,
too. E.g.:
try:
# some_complicated_task
...
# problem
raise SomeException ("Something's fishy, Dave")
...
# more serious problem
raise SomeSeriousError ("Something's screwed, Dave")
...
except OSError, e:
# clean up OS error
if e.errno == ...:
...
...
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.
Nils
--
Nils Philippsen / Red Hat / nphilipp@xxxxxxxxxx
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
