Re: is monit just a pain in the arse or what ?

[monit user]

Here is something related that you might want to keep in mind for debugging.
I just now changed the path to a disk resource from /dev/hda to /dev/sda
hda was the wrong drive for this machine, then I immediately did:

# monit reload
# monit status

But it still said:
Device 'rootfs'
  status                            Data access error

I had to do:

# monit quit
# monit
# monit status

And then I got:
The monit daemon 4.9 uptime: 0m
...
Device 'rootfs'
  status                            accessible

I had a similar situation with some other resources where I changed the path 
of the pid file (but not the name of the resource). So when making changes to 
the config, it seems to be a good idea to quit monit and restart if you are 
having trouble.

Closer to your exact problem, I suggested using strace for someone having pid 
problems and they were able to identify the issue using something like this:

strace -ttt -f -ff -o monitissue -e trace=file -p monit's_process_id

In your case, you'd want to strace both the running monit process and the 
command "monit summary" with a few different options instead of just 
trace=file to see where the communication breakdown was happening but 
trace=file should help pinpoint pid file and start/stop script issues. For the 
person having the pid trouble, it turned out that the start script was not 
executable and nothing was wrong with the pid file nor monit's interaction 
with the pid file.

For the record, I find monit to be the least frustrating and most lean and 
stable monitoring tool to build, install, configure and use with constant and 
timely free support, development, bug fixes and scrutiny of the code (and any 
issues that are brought to light) by the developer. I have monit instances 
that have run continuously for over a year without restarting or problems... 
Certain other tools (that share the same first few letters) made me want to 
quit using computers and become a sheep shearer. YMMV.

Martin Pala wrote:
> Can you try monit >= 4.8.2? In monit 4.8.1 the http thread was blocking 
> in when for example process was restarted via http interface.
>
> Thanks,
> Martin
>
> Alexey Zilber wrote:
> > I get this occasionally as well.  Two different system, same OS, one 
> > works fine, one does what you just described.  Both installed via the 
> > same rpm.
> >
> > Is there perhaps some resource or status file that monit maybe doesn't 
> > have permission to access?
> >
> > -Alex
> >
> > On 7/26/07, *andrew taylor* <address@hidden 
> > <mailto:address@hidden>> wrote:
> >
> >     Normally, when I ask monit for status, I get this...
> >
> >     address@hidden:~# monit summary
> >     monit: cannot read status from the monit daemon
> >
> >     This happens constantly and is frustrating and useless.
> >
> >     When I do get data, it tells me something like this...
> >
> >     Process 'rails_mongrel_9200' Execution failed
> >     Process 'rails_mongrel_9201' Execution failed
> >     Process 'rails_job' running
> >     Process 'rails_mailer' Execution failed
> >
> >
> >     uhh...not quite, if I ps, all the processes are running, all the pids
> >     are there, everything is fine.
> >
> >
> >     When I ask monit to start/stop by group, it usually ignores me.
> >
> >
> >     All these monit features, and to me, the basics are not even right.
> >
> >
> >     I am running Ubuntu Feisty server with the apt-get monit 
> > installed, so I
> >     did not screw anything up in the build/install.