monit-general
[Top][All Lists]
Advanced

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

Re: [monit] Monit alerts of failure to start but it succeeds


From: Moshe Cohen
Subject: Re: [monit] Monit alerts of failure to start but it succeeds
Date: Sat, 17 Nov 2007 03:09:34 +0200

Monit version is 4.10.1 .

It certainly does not wait 60 seconds. It is immediate.

I cannot write the PID file at the start of the script because I do not know what the PID would be yet.
The relevant part of the script looks like this:

            $0  _run &
            pid=$!
            kill -0 $pid    # just to be sure
            if [ $? = 0 ]
                then
                echo $pid > run/gzipper.pid
            fi

the first line call the daemon script (in this case it is a recursive call to same script but with '_run' argument)
I double check on the PID received that it is a running process and then write the PID file. All this happens with no delay.

If you cannot reproduce the problem I will create a full demo monit script and daemon script.

Moshe
 

On Nov 14, 2007 10:47 PM, Martin Pala < address@hidden> wrote:
When the service is not running, monit forks the start method and one
control thread (wait_start), which checks each second whether the
process has started successfully. If the process didn't started within
the timeframe of the poll cycle (in your case 60s), then the execution
failure is reported.

The "pidfile does not exist" messages are from the start control thread,
which waits for the process to start. When the process didn't created
the pidfile within 60s, in your case you should see ca. 60 messages in
verbose mode.

Can your start script write the pidfile in the beginning?

Which monit version do you use?


Thanks,
Martin



Moshe Cohen wrote:
> Apparently, it did not wait a cycle.
>
> I ran with -v. See output at end.
> I don't use "every".
>
> gzipper.sh is a short bash script that runs another "daemon" script with
> an endless loop in a background process, and writes the PID
> of that process in gzipper.pid .
> The above logs was spit out with no delay so it is reasonable that the
> last "gzipper.pid' does not exist" logs were there just because of timing.
> I.e. the daemon was run, the gzipper.pid file was not yet written, but
> monit already checked for it without waiting a cycle.
> My cycle is 60 seconds.
>
>
> monit: pidfile '/home/moshe/.monit.pid' does not exist
> monit: pidfile '/home/moshe/icpipe/run/gzipper.pid' does not exist
> monit: pidfile '/home/moshe/icpipe/run/gzipper.pid' does not exist
> 'gzipper' start: /home/moshe/icpipe/bin/gzipper.sh
> monit: pidfile '/home/moshe/icpipe/run/gzipper.pid' does not exist
> monit: pidfile '/home/moshe/icpipe/run/gzipper.pid' does not exist
> 'gzipper' failed to start
> Execution failed notification is sent to address@hidden <mailto:address@hidden>
> Starting gzipper:
> start gzipping loop
>
>
> On 11/13/07, *Martin Pala* < address@hidden
> <mailto:address@hidden>> wrote:
>
>     Please run monit in verbose mode (-v option) and check logs.
>
>     Monit currently waits one cycle for the process to start (unless the
>     "every" option is used). If the process starts slower, then it
>     reports error. If your testing cycle is short, you can also consider
>     making in slightly longer.
>
>     We plan to support method timeouts in the future:
>     http://www.tildeslash.com/monit/doc/next.php#38
>
>     Martin
>
>
>     On Nov 12, 2007, at 1:02 AM, Moshe Cohen wrote:
>
>      > Hi,
>      > Often when I start a process with Monit, I receive an alert that it
>      > has failed to start, even though it succeeds.
>      > My thinking is that Monit is checking the PID file before it is
>      > created.
>      > How does Monit time this check ?
>      >
>      > Moshe
>      >
>      > --
>      > To unsubscribe:
>      > http://lists.nongnu.org/mailman/listinfo/monit-general
>     <http://lists.nongnu.org/mailman/listinfo/monit-general>
>
>
>
>     --
>     To unsubscribe:
>     http://lists.nongnu.org/mailman/listinfo/monit-general
>
>
>
> ------------------------------------------------------------------------


reply via email to

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