[pisa-src] Re: r1505 - in trunk: libpisa/global.h libpisa/util.c pisacd/cdmain.c pisasd/sdmain.c
- From: René Hummen <rene.hummen@xxxxxxxxxxxxxxxxx>
- To: pisa-src@xxxxxxxxxxxxx
- Date: Tue, 03 Nov 2009 17:43:21 +0100
On Nov 3, 2009, at 5:33 PM, Thomas Jansen wrote:
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.
The duplication will be fixed with your proposition anyway. The code I
removed won't be needed
any further, so I won't revert that.
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).
Didn't think about that.
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.
To my mind it's important to not randomly start the first hipd in the
path, in order to
make developing and testing more reliable. Even though, there'll be
one hipd on
the productive system in 2 years or so.
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.
Agreed.
---
Dipl.-Inform. René Hummen, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen
Other related posts:
