Re: [OSR-devel] killall5 output

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> On 25/12/2009 21:16, Marc Grimme wrote:
> > On output of killall5:
> > It should output to the console. Which means you should see your
> printfs
> > on console.
> 
> That's what I thought - only it doesn't. killall5 starts, and nothing
> 
> happens after that. I wonder if the problem actually occurs before
> that, 
Try to first add an echo before killall5 is issued to see what would be called.
I often added a bash/sh call afterwards to test what's happening:
action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
sleep 5
action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}
->
echo "Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
bash
action $"Sending all processes the TERM signal..." /usr/comoonics/killall5 -15 ${KILLALL_OPTS}
sleep 5
action $"Sending all processes the KILL signal..."  /usr/comoonics/killall5 -9 ${KILLALL_OPTS}

Then you know what happens. I don't think bootsr does any harm see below.
In the shell you could also try your command.

> e.g. the fact that init.d/bootsr does it's "Stopping fuse dependent 
> services" by calling "cc_init stop"...
> 
> Except this should resolve to fuse_init, which doesn't actually appear
> 
> to be implemented. glusterfs_init is. But interestingly, cc_init stop
> 
> takes about 30 seconds to return even though it seems to be invoking a
> 
> non-existant function.
Thats something else. It is what it takes to detect where the chroot resides.
So I wouldn't bother with this.
> 
> Having said that, it seems to do "Stopping gfs dependent services",
> too, 
> which souldn't happen on glusterfs at all since it has nothing to do 
> with gfs, so I'm not sure right now where that's coming from...
It should cause your clustertype is "gfs". So basically this happens. This is a kind of not yet implemented part. As you are using an /etc/cluster/cluster.conf the clustertype needs to be gfs.
And bootsr stops all services relevant to the rootfs (glusterfs/fuse) and clustertype (gfs). So this is normal too.
> 
> > You need to copy it to /usr/comoonics/killall5.
> 
> Yes, did that.
Thought that. Just to be sure.
> 
> > You could
> > output the killall opts to console in order to see if the programs
> get
> > excluded within killing:
> > echo "/usr/comoonics/killall5 -15 ${KILLALL_OPTS}"
>  > just before it is called and you should see if it is called
> properly.
> 
> Did that, too, and that looks fine. But killall5 never returns, and 
> never prints any output.
Never returns is suspicious. Try to call it yourself.
> 
> > Background information for the latest versions (OT but perhaps
> > interesting information for further steps):
> > Since latest bootimage versions the shutdown process has slightly
> > changed. We don't need so many patches but just call our own
> version
> > of halt.local (called in rc.sysinit). halt.local should be from the
> > bootimage rpm a symlink to
> > /sbin/halt.local -> 
> /opt/atix/comoonics-bootimage/boot-scripts/com-halt.sh.
> >
> > Nevertheless the killall5 call is issued before (if I recall it
> right)
> > so the killall5-patch needs to be inplace.
> 
> All of which still doesn't explain why killall5 goes away and silently
> 
> dies. :(
Yes.
So that's the question.

> 
> > With latest versions of bootimage you can even enable the stepmode
> in the
> > com-halt.sh (means in halt/reboot mode). There should be a skript
> called
> > /opt/atix/comoonics-bootimage/com-chroot. This helps you get
> chrooted into
> > the exitrd (former ramdisk of initrd). By default in
> /var/comoonics/chroot.
> > Then just issue a "setparameter step" and the reboot/halt will ask
> for
> > userinput after every command.
> >
> > Unfortunatly this does not help for killall5 as this is called
> before.
> 
> And even if it was applicable here, the key problem is that stepping 
> through wouldn't help. I know where it's going wrong, I just can't see
> 
> why. killall5 starts, and then silently locks up.
> 
> Gordan
> P.S.
> Again, should I CC to the list?
Yes. I'll do. I didn't see this. Thought you had.
-- 

Marc Grimme

Tel: +49 89 4523538-14
Fax: +49 89 9901766-0
E-Mail: gr...@at...

ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 |
85716 Unterschleissheim | www.atix.de | www.open-sharedroot.org

Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: 
DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss