> On 09 Mar 2015, at 07:04, Adam Nielsen <[email protected]> wrote:
>
>> Assuming you are running monit from init, it might work to do an
>>
>> init q
>>
>> to force init to rescan what it's running - then try killing it. Just
>> a guess really.
>>
>> Hmm, actually, I seem to recall hitting this once before, and I think
>> what it required was to comment out monit from the /etc/inittab, then
>> I was able to kill it. I think. It was a while back.
>
> Nah not running from inittab. Looks like the "D" state it's stuck in
> is a kernel uninterruptible state, so monit must have done something
> that the kernel is now stuck in.
>
> I'm a bit surprised that's enough to lock up monit though - I expected
> monit would run all its tests in other threads/processes so a system
> call that never returned wouldn't be a problem! Right now this one
> issue has completely locked up monit so it's not doing any checks at
> all, related to this problem or not!
>
> Cheers,
> Adam.
>
Hi Adam,
few questions:
1.) which Monit version it is? (monit -V)
2.) which Monit platform it is? (linux/freebsd/... ?)
3.) please can you provide backtrace of monit?:
gdb <path>/monit -p <monit's pid>
gdb> thr apply all bt
4.) please send monit log (enabled with "set logfile" statement)
Regards,
Martin
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
