On Wed, 27 Jun 2007, Lars Marowsky-Bree wrote:
> On 2007-06-26T14:10:16, Madison Kelly <[EMAIL PROTECTED]> wrote:
>
> > Madison Kelly wrote:
> > >Filesystem[3233]: 2007/06/25_16:20:07 ERROR: Setup problem:
> > >Couldn't find utility fsck
> >
> > I finally figured this out... Turns out the file:
> > /usr/lib/ocf/resource.d/heartbeat/Filesystem had the entry 'FSCK=fsck'.
> > Changing that entry to: 'FSCK=/sbin/fsck' made things work.
>
> There seems to have been a built error here on Debian.
>
> We've fixed this in hg.linux-ha.org/dev; it'll now additionally search
> the path for the command if required.
Does that fix happen to be Dejan's "e898fa7b59d3"? Technically, it may
work. But I think it is the wrong place for correcting this flaw.
Which brings me on to ...
Actually, I think we have a deeper problem in the build system, both with
a lack of consistency in handling such paths, and in many cases I think
deviating from the spirit of autoconf.
This may be getting too technical for the general "linux-ha" list, so I'm
Cc:ing to "linux-ha-dev", which might be a more appropriate place to
follow this up.
In autoconf, we widely use "AC_PATH_PROGS(variable,prog-to-check-for)".
That's good. Example:
AC_PATH_PROGS(PYTHON, python)
If the "prog-..." is found, variable is set to the full pathname,
otherwise it is not set. That's good and clean.
BUT ... we often use the additional, optional "value-if-not-found", which
I think we should be cautious about for true portability. And then,
worse, we set that to the simple program name; remember that the whole
point of "AC_PATH_PROGS" is to set the variable to a full pathname.
I suggest we need to rationalise:
1. Wherever possible our autoconf should simply use the basic:
AC_PATH_PROGS(variable,prog-to-check-for)
If it is not found we leave it blank, and let other code handle the
result. Often that other code might be elsewhere in "configure", for
instance if the absence of "prog..." is likely to be a show-stopper for
all heartbeat installations. Otherwise it could be (for instance)
run-time handling of the absence (empty variable) in a shell script.
2. In some cases (such as when we know that a command is highly specific
to a particular OS), there may be an argument for "value-if-not-found"
being used. I would suggest that this is infrequent. If it really is
necessary then it should follow the spirit and be the full pathname.
I cannot see any argument for it ever being the simple name.
Example 1: Assuming "mdadm" is Linux-specific. If we really need the
"value-if-not-found" option (do we really?) then its current:
AC_PATH_PROGS(MDADM, mdadm, /sbin/mdadm)
would be OK (OS-specific, and the fallback option is a full pathname).
Example 2: The current "fsck" is:
AC_PATH_PROGS(FSCK, fsck, fsck)
I argue that this is clearly wrong: "fsck" is multi-platform so we
should use the simple form (without the final ", fsck" clause), and
we cannot second guess its location (Linux: /sbin Solaris: /usr/sbin).
How does that seem?
(In the original poster's problem, if "fsck" was present, then configure
should have found it (or there was something flawed with his build process
which needs addressing). If it was absent, then simply setting a full
pathname isn't going to find it. The thing that is going to use it (or
something else in the build process) needs to be able to respond
appropriately to its absence.)
Thoughts?
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
