help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

using 'processes:' to stop processes


From: Ed Brown
Subject: using 'processes:' to stop processes
Date: Thu, 09 Dec 2004 16:10:19 -0700

This has come up before, obliquely at least, in a couple of threads
("Re: matches=0 still triggers action", and "Re: Killed wrong proc!"),
but I'd like to raise the issue again to restate an aspect of it that I
don't think has been made clear, and to keep the issue or need for a
solution alive.  

There is no simple way to use 'processes:' to kill processes that
shouldn't be running, when 'signal=' is not the right tool for the job. 
A previous suggestion was to add support for 'services', or the init
scripts start/stop functionality directly.  

I think that what's needed, and would be preferable in my view (and
maybe simpler to implement?), is just to be able to define a
shellcommand string to execute when a process IS running, in exactly the
same way that the 'restart' string is executed when a process isn't
running. This would allow for similiar flexibility as exists with
'restart', for example, removing start links (chkconfig) AND stopping
the service.

An earlier suggested workaround is use 'processes:' to define a class,
and then use a qualified 'shellcommands:' action.  This works, except
that it is necessary to also declare a phony 'restart' command
(/bin/true or /bin/false both work fine).  Without the restart command,
no define= or elsedefine= options are processed.  All in all, this is
somewhat kludgy, and it just seems intuitive to expect to be able to
handle all this within 'processes:'.

thanks,
Ed  
  

On Tue, 2004-11-02 at 10:04, Brendan Strejcek wrote:
> David E. Nelson wrote:
> > I still don't have a clear idea of how to stop 'lpsched' since
> > /etc/init.d/lp uses 'lpshut' rather than signalling 'lpsched' to die.
> > Since the OS designers specifically use 'lpshut' (and it's not a
> > script that simply kills either) to stop 'lpsched' and its friends (if
> > any), I'd rather use that method rather than kill. Ideas?
> define=someclass in the process stanza, and a shellcommands action
> triggered by someclass:: maybe?








reply via email to

[Prev in Thread] Current Thread [Next in Thread]