[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvz-users
Subject:    [Users] /etc/init.d/service stop
From:       peter.senna () gmail ! com (Peter Senna Tschudin)
Date:       2010-07-25 23:19:38
Message-ID: AANLkTinSzOJuL0y1XxNZex9=pqUomSDU+d88r4=ALVgZ () mail ! gmail ! com
[Download RAW message or body]

Gregor,

Thank you!

Alexander,

I'm running a daemon to collects information about the host like cpu
and memory utilization. Thank you for the help. I'll try to fix it by
modifying the start/stop script.

Peter

On Sun, Jul 25, 2010 at 11:58 PM, Solar Designer <solar@openwall.com> wrote:
> On Sun, Jul 25, 2010 at 11:35:41PM -0300, Peter Senna Tschudin wrote:
> > When I type:
> > /etc/init.d/ganglia-monitor stop
> > 
> > On my Host physical server, it shuts down all the running "gmond"
> > processes both in host and in my VEs. How can I avoid this?
> 
> It sounds like you need to enhance the startup script to use pidfiles -
> and perhaps submit the change upstream.
> 
> Alternatively, if the startup script is built around the Debian-derived
> start-stop-daemon program, then it can instruct this program to only
> signal processes that match a particular instance of an executable file.
> 
> On Owl, we use both approaches at once. ?We defined Red Hat'ish daemon(),
> etc. shell functions, which are expected by Red Hat'ish service startup
> scripts, to be built upon a revision of start-stop-daemon instead. ?This
> means that even third-party Red Hat'ish service startup scripts that do
> not use pidfiles but do use daemon() behave better in this respect on Owl
> (than they do e.g. on CentOS) due to start-stop-daemon's checks via /proc.
> 
> Our daemon(), etc. on top of start-stop-daemon:
> 
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/owl-startup/functions?rev=HEAD
>  
> Our changes to start-stop-daemon:
> 
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/SysVinit/sysvinit-2.85-alt-owl-start-stop-daemon.diff?rev=HEAD
>  
> Finally, the host system is supposed to run software essential to
> administering the system only. ?It sounds like this specific service
> might in fact be essential in your case, but I wanted to point this out
> anyway. ?So most of the time the problem would not arise simply because
> there would be no added services running on the host system.
> 
> Alexander
> 



-- 
Peter Senna Tschudin
peter.senna@gmail.com
gpg id: 48274C36


[prev in list] [next in list] [prev in thread] [next in thread]