[pisa-src] Re: r1505 - in trunk: libpisa/global.h libpisa/util.c pisacd/cdmain.c pisasd/sdmain.c
- From: Thomas Jansen <mithi@xxxxxxxxx>
- To: pisa-src@xxxxxxxxxxxxx
- Date: Tue, 3 Nov 2009 17:33:18 +0100
On Tue, Nov 03, 2009 at 04:50:31PM +0100, René Hummen wrote:
> Author: hummen
> Date: Tue Nov 3 16:50:30 2009
> New Revision: 1505
>
> Log:
> Modified behavior of pisa*d when hipd is not started upfront.
>
> The previous implementation would start a hipd from the path.
> Thus, it would be unknown to the user, which hipd is running
> at the moment. This is especially fatal, when different
> versions are available on the host and the user wants to use
> a specific one.
I'm not very fond of the patch. First of all you removed a central function
(in the next patch) from libpisa that was the one and only place to offer
that functionality in favor of duplicate code in pisa{c,s}d. You should move
the common code to libpisa again to remove the duplication and keep the init
functions lean.
Second point is that pisa{c,s}d will now wait indefinitely for a hipd to come
up eventually, spamming the user with stderr messages. According to the
comment it is done before we fork to the background, so using this in an init
script can block the whole boot process indefinitely if no hipd is started
before (or one that has died in between).
The third issue is that a typical installation will have only one HIP daemon.
I'm not talking about the test setups we developers run but the deployment
scenario. The only case where I see a need for several versions of hipd on a
system is to run test against a specific version. In that case, the version
would have been started by hand anyway, so the pisa{c,s}d code wouldn't have
come into play.
A really clean solution in my eyes would be to simply terminate if hipd is not
running without trying to start it ourselves and print an error message why we
quit. Leave the rest up to the user (or the calling script). To automate this
you could allocate a specific exit code to distinguish the reasons for the
exit in a script. Making sure that the dependencies are met is IMHO not
responsibility of the binary but of the initscript anyway.
--
Thomas Jansen, "Mithi" --- mithi@xxxxxxxxx
GPG 9D5C682B, feel free to sign or encrypt your mail
Other related posts:
