Martin Knoblauch said on Thu, Oct 13, 2005 at 06:31:30PM -0700:
>  to your first problem - I actually suspect a problem with your setup.
> Never seen a "/dev2/" before. Google shows:
> 
> http://lists.debian.org/debian-kernel/2005/05/msg00319.html
 
It's actually not a problem in our setup, as such; it happens when you
use the Debian default initrd kernel.  Basically, /dev2/root2 is the
initrd kernel device for the "real" root filesystem, instead of
/dev/root (which was the micro-root filesystem contained within the
initrd).

Here's what our /proc/mounts looks like:

rootfs / rootfs rw 0 0                                                          
/dev2/root2 / ext3 rw 0 0                                                       
proc /proc proc rw,nodiratime 0 0                                               
sysfs /sys sysfs rw 0 0                                                         
devpts /dev/pts devpts rw 0 0                                                   
tmpfs /dev/shm tmpfs rw 0 0                                                     
/dev/hda2 /var ext3 rw 0 0                                                      
/dev/hda3 /srv ext3 rw 0 0e [Msgs:5
/dev/hdc1 /home ext3 rw 0 0                                                     
usbfs /proc/bus/usb usbfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

> Also, your fix seems very unportable. What happens when there is a
> "/dev3/" out there some day? *If* the code needs changing at all, *I*
> would change it to check just for "/dev" and a length of more than 4
> chars. Anybody else has this kind of entries?
 
Considering that this is basically an attempt to get ganglia to work out
of the box on Debian... I don't think it's a portability issue.  If
there ends up being a /dev3 someday, then perhaps the person who
encounters it will submit a patch then.

>  For the second problem I would prefer that updating the pid file is
> done in the invoking init script. This way every distribution can do
> what they need to do and keep the core code portable. Do not forget
> that gmond and gmetad need to run on non-Linux platforms.

Uh, you're kidding right?  There's a lot of portable software out there
that writes a pidfile but doesn't do so on Windows.  Trying to dump the
pidfile from the init script doesn't work very well since gmond and
gmetad daemonize; the script can hack around that, but it's much cleaner
to just have the daemons to it themselves.

Now, we can certainly make the pidfile writing an autoconf check
(including the path to where the pidfile goes) and an entry in
config.h.in, so it's nicely encapsulated.  Would that be better?

M

Attachment: signature.asc
Description: Digital signature

Reply via email to