help-cfengine
[Top][All Lists]
Advanced

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

Re: Killed wrong proc!


From: Phil D'Amore
Subject: Re: Killed wrong proc!
Date: Wed, 22 Sep 2004 11:18:41 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Indeed that can be fun. One thing to keep in mind though is that the matches doesn't affect restart or signal, only inform (and IIRC define/elsefdefine). The matches= in my statement could be left out and the restart behavior still stands, since it only runs when there are exactly 0 matches. I only have it there to set a threshold for the inform= line.

Chip Seraphine wrote:

I've historically stayed away from matches= because of problems I've had with incorrect counts of matches. 'course, now that I know I can use filters, I might be revisiting that.

(Another fun one with matches: multithreaded Linux apps on older kernels. Heavy threads! Doh!)

On Wednesday 22 September 2004 10:00, Phil D'Amore wrote:
That's interesting. Things like this work for us (sorry I didn't have a postgres example):

   cfrole_squid_server::
       "squid "
           restart "/sbin/service squid start"
           matches=>1
           inform=on

The way I interpreted the docs was that the restart is run if nothing matches the pattern, and the signal is done if something does match the pattern. They're mutually exclusive in that way.

Also something to note there is the space in my squid pattern. The trailing space makes sure I only get the real squid procs and not the string squid in a path passed into some other process. That may work for you too.

Chip Seraphine wrote:

Because the restart command will not run unless I send either a TERM or a KILL, according to the reference. 'tis a hackaround. I could have it set
a
class and then let shellcommands execute the restart, but that is even kludgier.

It would be nice if we could say signal=dorestart or something like that to clue cfengine that we want to execute the restart line without sending a signal. (Or just allow signal 0 along with TERM and KILL, perhaps.)

Given that I have to send a signal, the reason for saying "restart" instead
of
"start" is that some Linux init scripts (esp with RedHat and SuSE)
sometimes
clean up pidfiles and such, IIRC. Doing a restart instead of a start makes you less likely to run into ugliness. The postfix script is not one of these, but it can't hurt.

On Wednesday 22 September 2004 09:15, Ted Zlatanov wrote:


On Tue, 21 Sep 2004, chip@trdlnk.com wrote:

In cfengine 2.1.10 on Solaris 2., this processes block:
                "postfix"
                        signal=TERM
                        restart "/etc/init.d/postfix restart"
Out of curiosity, doesn't the /etc/init.d/postfix script do the TERM
signal for you?  I know it's not what you're asking, but I'm trying to
figure out why you're going around the normal mechanism for restarting
Postfix.

Ted


_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine



--
Phil D'Amore                             "Sometimes there is a fine line
Senior System Administrator               between criminally abusive
Red Hat, Inc                              behavior and fun."
Office: 919.754.3700 x44395                 -- Ted the Generic Guy
Pager: 877.383.8795                            (Dilbert 4/19/2003)




--
Phil D'Amore                             "Sometimes there is a fine line
Senior System Administrator               between criminally abusive
Red Hat, Inc                              behavior and fun."
Office: 919.754.3700 x44395                 -- Ted the Generic Guy
Pager: 877.383.8795                            (Dilbert 4/19/2003)





reply via email to

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