Bug#614984: smtp protocol test issues both EHLO and HELO
Hello, Monit sends EHLO first and waits for "250" response ... if it fails or , then it tries HELO. It seems that your mailserver returned some different response. Please can you provide monit log (should contain more details) and network trace of the communication? Or if your mailserver is accessible via internet, please can you provide the address so i can test the behavior? Regards, Martin On Feb 24, 2011, at 6:37 PM, Romain Francoise wrote: > Package: monit > Version: 1:5.2.3-2 > Severity: normal > > I recently upgraded monit from version 1:5.1.1-1 to 1:5.2.3-2 and it > started reporting failures when checking a remote smtp server running > Exim 3.36. A network capture shows that the new version issues both EHLO > and HELO, even though the first EHLO was successful. Exim doesn't like > this and closes the connection, which monit interprets as a failure. > The previous version correctly issued QUIT after the successful EHLO, so > this appears to be a regression. > > Thanks, > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (900, 'unstable'), (850, 'testing'), (800, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.37-ore-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages monit depends on: > ii libc6 2.11.2-11 Embedded GNU C Library: Shared > lib > ii libpam0g 1.1.2-2Pluggable Authentication Modules > l > ii libssl0.9.8 0.9.8o-5 SSL shared libraries > ii lsb-base 3.2-27 Linux Standard Base 3.2 init > scrip > > monit recommends no packages. > > monit suggests no packages. > > -- Configuration Files: > /etc/default/monit changed [not included] > /etc/monit/monitrc [Errno 13] Permission denied: u'/etc/monit/monitrc' > > -- no debconf information > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614984: smtp protocol test issues both EHLO and HELO
Please can you attach the monit log or look for SMTP protocol test errors in it? Full network trace will help as well ... the transcript doesn't contain timing - it is possible that Exim response timed out in Monit if it took too long. Regards, Martin On Feb 25, 2011, at 6:42 PM, Romain Francoise wrote: > Martin Pala writes: > >> Monit sends EHLO first and waits for "250" response ... if it >> fails or , then it tries HELO. It seems that your mailserver >> returned some different response. > > Here's a network capture (edited for privacy, the server is not > public): > > S: 220 smtp.localdomain ESMTP Exim 3.36 #1 Fri, 25 Feb 2011 18:30:37 +0100 > C: EHLO localhost > S: 250-smtp.localdomain Hello [192.168.1.1] > 250-SIZE > 250-PIPELINING > 250 HELP > C: HELO localhost > > The EHLO answer looks correct to me, monit should not continue with > HELO. > > -- > Romain Francoise > http://people.debian.org/~rfrancoise/ > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643019: monit: FTBFS: configure: error: Architecture not supported: `uname`.
Hi, we we have added support for GNU/kFreeBSD to Monit … it will be part of next release (monit 5.4). It is necessary to install the libkvm-dev package to compile Monit on kFreeBSD. Regards, Martin On Sep 26, 2011, at 6:06 PM, Christoph Egger wrote: > Package: src:monit > Version: 1:5.3-1 > Severity: serious > Tags: sid wheezy > Justification: fails to build from source (but built successfully in the past) > > Hi! > > Your package failed to build on the kfreebsd-* buildds: > > checking for sys/filio.h... yes > configure: error: Architecture not supported: `uname`. > configure: error: ./configure failed for libmonit > > Full build log at > https://buildd.debian.org/status/fetch.php?pkg=monit&arch=kfreebsd-amd64&ver=1%3A5.3-1&stamp=1316043872 > > Regards > >Christoph > > If you have further questions please mail debian-...@lists.debian.org > > -- > 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 > Debian Developer | Lisp Hacker | CaCert Assurer > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555741: monit: Port for HTTP not bound
Hi, please run monit in verbose mode (using -v option) and check logs. Did monit started successfully? Is there any other process listening on port 2812? Regards, Martin On Nov 11, 2009, at 4:17 PM, Fladischer Michael wrote: > Package: monit > Version: 1:5.0.3-3 > Severity: normal > > Running monit as root (/usr/sbin/monit -c /etc/monit/monitrc -s > /var/lib/monit/monit.state) and the following lines in > /etc/monit/monitrc does not result in monit listening on port 2812 for > HTTP requests: > > set httpd port 2812 and > use address localhost > > $ sudo netstat -ntpl |grep monit > shows no listening port. > > -- System Information: > Debian Release: squeeze/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages monit depends on: > ii libc6 2.10.1-6 GNU C Library: Shared libraries > ii libpam0g 1.1.0-4Pluggable Authentication Modules > l > ii libssl0.9.8 0.9.8k-5 SSL shared libraries > > monit recommends no packages. > > monit suggests no packages. > > -- no debconf information > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652715: monit: spurious warning "include files not found '/etc/monit/conf.d/*'"
Hello, good point, there is no need to emit warning in this case - we have removed the warning from the upstream source code, the next release (monit 5.3.2) will be silent if no include files were found. Best regards, Martin On Dec 20, 2011, at 10:15 AM, Vincent Lefevre wrote: > Package: monit > Version: 1:5.3.1-2 > Severity: minor > > When the monit daemon is started: > > Starting daemon monitor: monit/etc/monit/monitrc:246: Warning: include files > not found '/etc/monit/conf.d/*' > . > > I don't see any reason for a warning, in particular here where this > directory is empty by default! > > Alternatively, I think an empty file could be created in the directory > to avoid the warning. > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages monit depends on: > ii libc62.13-23 > ii libpam0g 1.1.3-6 > ii libssl1.0.0 1.0.0e-3 > ii lsb-base 3.2-28 > > monit recommends no packages. > > Versions of packages monit suggests: > ii postfix [mail-transport-agent] 2.8.5-1.1 > > -- Configuration Files: > /etc/monit/monitrc [Errno 13] Permission denied: u'/etc/monit/monitrc' > > -- no debconf information > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#621047: monit: FTBFS with ssv2 removal: ssl.c:645: undefined reference to `SSLv2_client_method'
Hello, the patch is attached Best regards, Martin ssl.patch Description: Binary data On Apr 6, 2011, at 6:10 AM, Cyril Brulebois wrote: > Source: monit > Version: 1:5.2.5-1 > Severity: serious > Justification: FTBFS > > Hi, > > your package FTBFS with: > | gcc -rdynamic alert.o collector.o control.o daemonize.o env.o event.o > file.o gc.o http.o log.o md5.o monitor.o net.o process.o sendmail.o sha.o > signal.o socket.o spawn.o ssl.o state.o status.o util.o validate.o xmalloc.o > xml.o device/device_common.o http/base64.o http/cervlet.o http/engine.o > http/processor.o process/process_common.o protocols/apache_status.o > protocols/clamav.o protocols/default.o protocols/dns.o protocols/dwp.o > protocols/ftp.o protocols/generic.o protocols/gps.o protocols/http.o > protocols/imap.o protocols/ldap2.o protocols/ldap3.o protocols/lmtp.o > protocols/memcache.o protocols/mysql.o protocols/nntp.o protocols/ntp3.o > protocols/pgsql.o protocols/pop.o protocols/postfix_policy.o > protocols/protocol.o protocols/radius.o protocols/rdate.o protocols/rsync.o > protocols/sip.o protocols/smtp.o protocols/ssh.o protocols/tns.o > device/sysdep_LINUX.o process/sysdep_LINUX.o y.tab.o lex.yy.o -lfl -lpam > -lpthread -lcrypt -lresolv -lnsl -L/usr/lib -lssl -lcrypto -o monit > | ssl.o: In function `new_ssl_connection': > | /build/buildd-monit_5.2.5-1-i386-RcVJYW/monit-5.2.5/ssl.c:645: undefined > reference to `SSLv2_client_method' > | collect2: ld returned 1 exit status > | make[1]: *** [monit] Error 1 > > Full build logs: > https://buildd.debian.org/status/package.php?p=monit > > KiBi. > > >
Bug#589895: Acknowledgement (squeeze version of /etc/init.d/monit seems to be missing -d $CHECK_INTERVALS)
The -d option is not necessary if 'set daemon ' is used in monit configuration file - monit will then start in daemon mode and test services every x seconds. For example (test every 180s ... no need for '-d 180' command line option): set daemon 180 Best regards, Martin On Jul 22, 2010, at 3:00 PM, Gary wrote: > An alternative to reverting the /etc/init.d/monit to Lenny behaviour > might be to add a new variable to /etc/default/monit > MONIT_OPTS="-d 180" > # We default to 180s (3min) check intervals > > That way /etc/init.d/monit might have a line > ARGS="$MONIT_OPTS -c $CONFIG -s /var/lib/monit/monit.state" > > This maintains the behaviour that people are used to from stable Debian, > and also might allow the flexibility to meet wishlist #541425 > > For very specific local requirement where a user needs to introduce a > start delay, > then emptying MONIT_OPTS > so that MONIT_OPTS='' in /etc/default/monit > allows the setting of any non regular settiing through other means > > ssh has a similar system > #grep OPTS /etc/default/ssh > SSHD_OPTS= > ( on some systems SSHD_OPTS is non empty to meet a local requirement ) > Experienced ssh users will know where to set enviroment variables and > per user ssh config files, if they want something very specific. > > On 22 July 2010 00:45, Debian Bug Tracking System > wrote: >> Thank you for filing a new Bug report with Debian. > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). Is the certificate self-signed or using public CA? Thanks, Martin Georges Toth wrote: Package: monit Version: 1:4.10.1-4 Severity: grave Justification: renders package unusable After having upgraded to lenny, the monit webinterface no longer works with client certificate authentication. While using Debian Etch, with the exact same configuration it worked fine. Here is the error logged by monit when trying to connect: monit[2067]: monit: The client did not supply a required client certificate! monit[2067]: monit: Openssl engine error: error:140D9115:SSL routines:func(217):reason(277) monit[2067]: monit: The client did not supply a required client certificate! -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages monit depends on: ii libc6 2.7-14 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-13 SSL shared libraries monit recommends no packages. monit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Georges Toth wrote: Quoting Martin Pala <[EMAIL PROTECTED]>: Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). set httpd port 28000 and use address 123.123.123.123 ssl enable pemfile /etc/ssl/ca_priv_pub.pem clientpemfile /etc/monit/client_certificates.pem ALLOWSELFCERTIFICATION Is the certificate self-signed or using public CA? It's a self-signed certificate. Besides the version, nothing changed on the server. Firefox (32bit binary, 3.x, gentoo) seems to be the problem here. Certificate is correctly installed, including root (with correct cert-permissions set in firefox). Firefox doesn't even ask for me to choose a certificate. On other website it on the other hand does. Really strange... I tried to replicate ... using self-compiled monit-5.0_beta4 with libssl-0.9.8g-13 on Debian-unstable with Iceweasel-3.0.3-2 works fine. Configuration: --8<-- set httpd port 2812 and use address 127.0.0.1 ssl enable pemfile /var/certs/monit.pem clientpemfile /var/certs/monit_client.pem allowselfcertification allow localhost --8<-- I can see the same error logged which you saw as well: --8<-- monit: Openssl engine error: error:140D9115:SSL routines:func(217):reason(277) --8<-- ... but the authentication works, and i don't see the error which you mentioned and which is root cause of the problem: --8<-- monit[2067]: monit: The client did not supply a required client certificate! --8<-- When i switched the Iceweasel's certificate setting: Edit->Preferences->Advanced->Encryption->"When a server requests my personal certificate" to "Ask me every time" i get the dialog which reports that Monit asked for certificate and allows to select the certificate. Summary: it's quite strange problem - in Monit there were no changes in SSL related code between 4.10.1 and 5.0_beta4 so they should work the same. It's possible that it's browser problem (on your side, konqueror worked and i have tested with Iceweasel alias Firefox without problem). Thanks, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#514709: event queue full if slots undefined
Hi,
this error was fixed in upcoming monit-5.0 which will be release ca.
during February-March.
Cheers,
Martin
On Feb 10, 2009, at 10:59 AM, General Stone wrote:
Package: monit
Severity: important
Version: 4.10.1-4
Hi,
Monit says that the event queue is full if "SLOTS" are not defined in
"set eventqueue" statement.
The following patch in the attachment correct this failure.
Greetings, Markus Naß
diff -ruN old/monit-4.10.1/file.c new/monit-4.10.1/file.c
--- old/monit-4.10.1/file.c 2007-08-12 20:02:48.0 +0200
+++ new/monit-4.10.1/file.c 2009-02-10 09:55:00.0 +0100
@@ -404,7 +404,7 @@
DIR *dir = NULL;
struct dirent *de = NULL;
- if(limit <= 0) {
+ if(limit = 0) {
LogError("%s: event queue full\n", prog);
return FALSE;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#479357: command 'monit status' doesn't work without /etc/monitrc
Note that it's possible to set the path to monitrc using the --sysconfdir configure option. If Debian package uses /etc/monit/monitrc by default (which is not in the hardcoded search path), it could be good to use the --sysconfdir to set the path properly. If on the other side the movement to /etc/monit/monitrc was users decision, then it's not bug and the user should recompile monit himself. Optionally we can add the /etc/monit/monitrc path to the hardcoded monit search path (it may look reasonable). Thanks, Martin anton.m.serov wrote: Package: monit Version: 1:4.10.1-3+b1 Severity: normal I've to create hardlink for 'monit status' to work: ln /etc/monit/monitrc /etc/monitrc Withoud this file monit exits with error message: monit: Cannot find the control file at ~/.monitrc, /etc/monitrc, /etc/monitrc, /usr/local/etc/monitrc or at ./monitrc -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24.3a.serov (SMP w/1 CPU core) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages monit depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-8 SSL shared libraries monit recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433164: monit: Segfault in 3-5 seconds after start
Hi, thanks for report ... it crashes in the http testing module. Can you please: 1.) get the snoop/tcpdump of the communication between monit and the target webserver? (so we can get the request/response which led to the crash) 2.) send the part of the monit configuration file which specifies the given service/webserver check? Thanks, Martin On Jul 15, 2007, at 11:09 AM, Stefan Alfredsson wrote: Alexey Bestchekov wrote: #0 0x2ace3273d8d7 in _IO_vfscanf_internal () from /lib/libc.so.6 #1 0x2ace3274c395 in vsscanf () from /lib/libc.so.6 #2 0x2ace32747ca8 in sscanf () from /lib/libc.so.6 #3 0x0041f7b7 in get_response (s=0x56ec30, H=0x7fff78d03a40) at protocols/http.c:473 #4 0x0041fb51 in do_redirect (H=0x7fff78d03a40) at protocols/http.c:431 the same problem exist in newer upstream version (4.9) Since the coredump is in libc/vfscanf, I'm guessing this may be 64 bit + locale related. Could you try these steps? 1. Unset LANG LC_CTYPE LC_ALL and other locale related variables and try to start. 2. print the variables to get_response() (like gdb monit ; run ; up ; up ; up ; print s; print H ) 3. (a bit more work) upgrade to a newer libc and recompile with that. I'm also CC'ing upstream if they have some ideas. Regards, Stefan -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.koi8r (charmap=KOI8-R) (ignored: LC_ALL set to ru_RU.koi8r) Versions of packages monit depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8c-4 SSL shared libraries monit recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474009: monit: dies if non-md5sum password found
Thanks for report :) the problem was fixed in monit cvs and will be part of next monit release (planned for next week). Btw. the htpasswd usage is described in monit manual (http://www.tildeslash.com/monit/doc/manual.php#basic_authentication), the default is cleartext, but you can set crypt or md5 (which is used in the example configuration). Martin Adrian Bridgett wrote: Package: monit Version: 1:4.10.1-3 I had told monit to use an htpasswd file with md5sums in it. However I just used "htpasswd" - I thought it uses md5sum by default, but actually it's crypt. So the passwords were _not_ valid md5sums. Unfortunately there are two asserts in util.c (line 1646 is the first one). So monit just "mysteriously" died. I figured it out by strace()ing it. It would be good to change these asserts to perhaps spit out warning message (bad MD5 password for user ...) but to _keep_ working. Thanks, Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#506923: typo in output of 'monit status'
Thanks for report, fixed in monit cvs, will be fixed in next monit release. Martin On Nov 26, 2008, at 12:32 AM, Chris Lawrence wrote: Package: monit Version: 1:4.10.1-4 Severity: minor In the output of 'monit status' for a process, monit refers to the # of child processes for a daemon as "childrens"; the correct plural of "child" in English is "children". -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-028stab059.5 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages monit depends on: ii libc6 2.7-16 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-14 SSL shared libraries monit recommends no packages. monit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#541139: uses gethostbyname() and thus does not work with "options inet6" in /etc/resolv.conf
Thanks :) Added to upstream. There were yet two additional gethostbyname() instances used in ICMP test and Monit's httpd server socket ... i have replaced them too. Martin On Aug 12, 2009, at 7:56 AM, Stefan Alfredsson wrote: Michael Stapelberg wrote: This is easily fixed by using getaddrinfo() (which is also beneficial for supporting IPv6 and for other reasons, see: http://udrepper.livejournal.com/16116.html ). Patch is attached. Thanks for the patch (which upstream will hopefully apply to their tree :). Please see the (soon uploaded) package and verify that it works OK. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787400: monit: Cannot initialize SSL server certificate handler
Hello,
please try to upgrade monit … the SSL implementation was refactored in 5.12, it
solved similar problem reported by other user
(https://bitbucket.org/tildeslash/monit/issue/117/failed-to-connect-to-collector).
Latest release is recommended: monit 5.13.
Regards,
Martin
> On 01 Jun 2015, at 08:36, Jens Siefert wrote:
>
> Package: monit
> Version: 1:5.9-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
> Can not connect to our MMONIT server.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> i tye to starting monit => service monit start
>
> * What was the outcome of this action?
> an error :(
> [CEST Jun 1 08:15:01] error: Cannot initialize SSL server certificate
> handler -- error:140A90A1:SSL routines:func(169):reason(161)
> [CEST Jun 1 08:15:01] error: M/Monit: cannot open a connection to
> https://mmonit.checkdomain.de:8443/collector
>
> * What outcome did you expect instead?
> a success connect
>
> *** End of the template - remove these template lines ***
>
>
> -- Package-specific info:
>
> Contents of /etc/monit/ directory:
> /etc/monit:
> total 52
> -rwx-- 1 root root65 May 31 12:14 apache2ctl.sh
> drwx-- 2 root root 4096 May 31 12:16 conf.d
> -rwx-- 1 root root 302 May 31 12:15 mailpipe.sh
> -rw--- 1 root root 10305 May 31 12:14 monitrc
> -rw--- 1 root root 11232 Sep 30 2014 monitrc.2015-05-31@12:14:36~
> drwxr-xr-x 2 root root 4096 Jun 1 08:14 monitrc.d
> -rwx-- 1 root root 4422 May 31 12:14 proclist.pl
> drwxr-xr-x 2 root root 4096 Jun 1 08:14 templates
>
> /etc/monit/conf.d:
> total 68
> -rw--- 1 root root 475 May 31 12:18 apache2.conf
> -rw--- 1 root root 178 May 31 12:14 apache2ctl.conf
> -rw--- 1 root root 258 May 31 12:15 atd.conf
> -rw--- 1 root root 268 May 31 12:15 cron.conf
> -rw--- 1 root root 504 May 31 12:15 dovecot.conf
> -rw--- 1 root root 358 May 31 12:15 fail2ban.conf
> -rw--- 1 root root 501 May 31 12:15 filesystem.conf
> -rw--- 1 root root 189 May 31 12:14 mailpipe.conf
> -rw--- 1 root root 472 May 31 12:14 monit-to-mmonit.conf
> -rw--- 1 root root 399 May 31 12:15 mysql.conf
> -rw--- 1 root root 935 May 31 12:15 postfix-hold.conf
> -rw--- 1 root root 396 May 31 12:15 postfix.conf
> -rw--- 1 root root 405 May 31 12:15 proftpd.conf
> -rw--- 1 root root 494 May 31 12:16 robot.conf
> -rw--- 1 root root 375 May 31 12:15 ssh.conf
> -rw--- 1 root root 802 May 31 12:14 system.conf
> -rw--- 1 root root 526 May 31 12:15 unbound.conf
>
> /etc/monit/monitrc.d:
> total 60
> -rw-r--r-- 1 root root 481 Sep 30 2014 acpid
> -rw-r--r-- 1 root root 641 Sep 30 2014 apache2
> -rw-r--r-- 1 root root 456 Sep 30 2014 at
> -rw-r--r-- 1 root root 692 Sep 30 2014 cron
> -rw-r--r-- 1 root root 603 Sep 30 2014 mdadm
> -rw-r--r-- 1 root root 670 Sep 30 2014 memcached
> -rw-r--r-- 1 root root 704 Sep 30 2014 mysql
> -rw-r--r-- 1 root root 522 Sep 30 2014 nginx
> -rw-r--r-- 1 root root 472 Sep 30 2014 openntpd
> -rw-r--r-- 1 root root 951 Sep 30 2014 openssh-server
> -rw-r--r-- 1 root root 684 Sep 30 2014 pdns-recursor
> -rw-r--r-- 1 root root 1422 Sep 30 2014 postfix
> -rw-r--r-- 1 root root 780 Sep 30 2014 rsyslog
> -rw-r--r-- 1 root root 502 Sep 30 2014 smartmontools
> -rw-r--r-- 1 root root 310 Sep 30 2014 snmpd
>
> /etc/monit/templates:
> total 12
> -rw-r--r-- 1 root root 164 Sep 30 2014 rootbin
> -rw-r--r-- 1 root root 160 Sep 30 2014 rootrc
> -rw-r--r-- 1 root root 164 Sep 30 2014 rootstrict
>
>
> -- System Information:
> Debian Release: 8.0
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages monit depends on:
> ii libc62.19-18
> ii libpam0g 1.1.8-3.1
> ii libssl1.0.0 1.0.1k-3
> ii lsb-base 4.1+Debian13+nmu1
>
> monit recommends no packages.
>
> Versions of packages monit suggests:
> ii postfix [mail-transport-agent] 2.11.3-1
> pn sysvinit-core
>
> -- Configuration Files:
> /etc/logrotate.d/monit changed:
> /var/log/monit/monit.log {
>daily
>rotate 7
>size 1M
>missingok
>create 0660 root root
>compress
>delaycompress
>postrotate
> /etc/init.d/monit force-reload > /dev/null
>endscript
> }
>
> /etc/monit/monitrc changed:
> set daemon 120 # check services at 2-minute intervals
> with start delay 20 # optional: delay the first check by 4-minutes (by
> set logfile /var/log/monit/monit.log
> set idfile /var/log/monit/monit.id
> set st
Bug#787400: monit: Cannot initialize SSL server certificate handler
> On 08 Jun 2015, at 11:15, Sergey Kirpichev wrote:
>
> tags 787400 +moreinfo
> thanks
>
> Hello,
>
> On Mon, Jun 1, 2015 at 2:43 PM, Martin Pala wrote:
>> regarding the hostname … please check your monit configuration - if the
>> “check system ” statement is used, then you give the system a custom
>> name which overrides the hostname with a “” => if you have
>> “check system localhost”, you will see “localhost”.
>
> Sorry, Martin, but right now this looks as a regression. I assume that
> the current configuration was working on < 5.13.
>
> Jens, I'm wrong? Could you provide used monit configuration, related
> to the example ("check system", apache configuration, etc).
>
> PS: Please CC to the bug thread, unless you intentionaly willing
> to hide some information.
Actually the original behaviour was bug - the name used in the “check system”
was always intended to be visible in M/Monit, snip from Monit 5.9 manual (see
the last sentence in the snip):
—8<—
=item 7. CHECK SYSTEM
The system name is usually hostname, but any descriptive name can be
used. You can use the variable $HOST as the name, which will expand to
the hostname. This test allows one to check general system resources
such as CPU usage (percent of time spent in user, system and wait),
total memory usage or load average. The unique name is used as the
system hostname in mail alerts and when M/Monit is configured, then
also as initial name of the host entry in M/Monit.
—8<—
Monit 5.13 fixes the problem - the “localhost” name is configuration issue …
“$HOST” should be used if the real hostname is needed instead of custom name.
I’m sorry about the bug thread … i wanted to post the data to it and used
“reply-all” to the original message, which automatically includes
“787400-qu...@bugs.debian.org” - i guess the “-quiet” postfix makes the message
invisible in the thread, changing it to “787...@bugs.debian.org” instead.
Regards,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#847196: monit segfault on stop and start
Sorry for typo in the explanation ... the "token" comes *after* "strlen(D)" in
the patch - in short:
integer "strlen(D)" is used as string argument for "Cookie:
securitytoken=%s\r\n" => CRASH
string "token" is used as integer argument for "Content-Length:
%d\r\n" ... harmless, but will give wrong content length, so the POST request
will fail
Best regards,
Martin
> On 12 Dec 2016, at 14:06, Martin Pala wrote:
>
> Hello,
>
> the problem is in debian patch (5.4-2+deb7u2):
>
> --- a/src/collector.c
> +++ b/src/collector.c
> @@ -64,10 +64,13 @@
> */
> static int data_send(Socket_T socket, Mmonit_T C, const char *D) {
> char *auth = Util_getBasicAuthHeader(C->url->user, C->url->password);
> +MD_T token;
> + Util_getToken(token);
> int rv = socket_print(socket,
> "POST %s HTTP/1.1\r\n"
> "Host: %s:%d\r\n"
> "Content-Type: text/xml\r\n"
> + "Cookie: securitytoken=%s\r\n"
> "Content-Length: %d\r\n"
> "Pragma: no-cache\r\n"
> "Accept: */*\r\n"
> @@ -79,6 +82,7 @@ static int data_send(Socket_T socket, Mm
> C->url->path,
> C->url->hostname, C->url->port,
> strlen(D),
> + token,
> prog, VERSION,
> auth?auth:"",
> D);
>
>
>
> the format string contains "Cookie: securitytoken=%s\r\n" before
> "Content-Length: %d\r\n", but the token argument comes before strlen(D) in
> the position for Content-Length argument - the program then reads from this
> integer value as if it would be pointer.
>
> The securitytoken in collector is not needed at all - the CSRF protection is
> related to Monit's own HTTP API (the securitytoken cookie is not present in
> upstream). To fix the problem, just drop the collector.c part of the patch.
>
> Best regards,
> Martin
>
>
>
>> On 12 Dec 2016, at 13:22, Sergey B Kirpichev wrote:
>>
>> On Mon, Dec 12, 2016 at 01:11:38PM +0100, Arthur Hoffmann wrote:
>>> Ok, now I have checked my config files and found out that it
>>> works with the latest package if I remove the following line:
>>>
>>> set mmonit https://USER:PASSWORD@URL:PORT/collector
>>
>> Ok, I see. I don't use closed-source software, so I can't help.
>>
>> Perhaps, other maintainers can.
>>
>>> I'm using Monit with the latest M/Monit v3.6.2.
>>
>> There is 5.20.0 in backports (that fixes CVE). Could you test
>> this version too, as it could be that your problem is relevant
>> to upstream package?
>>
>
Bug#847196: monit segfault on stop and start
Hello,
the problem is in debian patch (5.4-2+deb7u2):
--- a/src/collector.c
+++ b/src/collector.c
@@ -64,10 +64,13 @@
*/
static int data_send(Socket_T socket, Mmonit_T C, const char *D) {
char *auth = Util_getBasicAuthHeader(C->url->user, C->url->password);
+MD_T token;
+ Util_getToken(token);
int rv = socket_print(socket,
"POST %s HTTP/1.1\r\n"
"Host: %s:%d\r\n"
"Content-Type: text/xml\r\n"
+ "Cookie: securitytoken=%s\r\n"
"Content-Length: %d\r\n"
"Pragma: no-cache\r\n"
"Accept: */*\r\n"
@@ -79,6 +82,7 @@ static int data_send(Socket_T socket, Mm
C->url->path,
C->url->hostname, C->url->port,
strlen(D),
+ token,
prog, VERSION,
auth?auth:"",
D);
the format string contains "Cookie: securitytoken=%s\r\n" before
"Content-Length: %d\r\n", but the token argument comes before strlen(D) in the
position for Content-Length argument - the program then reads from this integer
value as if it would be pointer.
The securitytoken in collector is not needed at all - the CSRF protection is
related to Monit's own HTTP API (the securitytoken cookie is not present in
upstream). To fix the problem, just drop the collector.c part of the patch.
Best regards,
Martin
> On 12 Dec 2016, at 13:22, Sergey B Kirpichev wrote:
>
> On Mon, Dec 12, 2016 at 01:11:38PM +0100, Arthur Hoffmann wrote:
>> Ok, now I have checked my config files and found out that it
>> works with the latest package if I remove the following line:
>>
>> set mmonit https://USER:PASSWORD@URL:PORT/collector
>
> Ok, I see. I don't use closed-source software, so I can't help.
>
> Perhaps, other maintainers can.
>
>> I'm using Monit with the latest M/Monit v3.6.2.
>
> There is 5.20.0 in backports (that fixes CVE). Could you test
> this version too, as it could be that your problem is relevant
> to upstream package?
>
Bug#352065: monit: treats ntp3 answers with leap indicator set as errors
Thanks, you are right :) It is fixed in monit cvs now - will be part of next monit release. Cheers, Martin Janusz Krzysztofik wrote: Package: monit Version: 1:4.5-1 Severity: normal Tags: patch I use monit to monitor a pool of my real ntp servers in an lvs cluster. From time to time a server or two start answering with leap indicator set to +1. Monit counts this as an error and, using my config file settings, removes the server from the lvs pool. I can check the server by other means (ntpdate, ntpdc) and see it is ok and still can serve clients. If my understanding of ntp leap indicator meaning and usage is correct, fully functional ntp servers can set leap indicator bits to 01 or 10, and more, this warning is propagated downstream, so every ntp server synchronized to a pool.ntp.org, for example, can and will be affected form time to time. Included patch limits error condition to 11, that I believe means "not synchronized". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353875: monit: exec doesnt work
Joerg Jaspert wrote: Package: monit Severity: important Hi monit has the useful "exec" way to run an application whenever a condition is there. The only problem is that this does not work for "if X restarts within X cycles then exec foo" Hi, this is not bug, but feature request. This statement serves just for timeout currently, as described here: http://www.tildeslash.com/monit/doc/manual.php#service_timeout You can use the stack of testing rules in event ratio context instead: http://www.tildeslash.com/monit/doc/manual.php#service_tests Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#740803: [monit] sysvinit should move from recommends to suggests
On 05 Mar 2014, at 10:02, Adrien CLERC wrote: >> monit is not about its web gui. It is a system for proactive >> monitoring, and these features of monit can conflict with >> systemd's configuration (e.g. Restart=on-failure). > Yes, I know that monit is really useful with stateless init systems. But > it can also be useful with others. > I don't know how the dependency solver handles this, but right now, > monit will trigger sysvinit installation, but systemd-sysv will remove > it, as it is referenced as a conflict. > If systemd is a real problem for monit, it should be better to add > systemd (or systemd-sysv) as a conflictual package. > > I am not trying to push systemd nor sysv. I am just trying to avoid a > war for future users :) And I think monit still has some features that > could be useful, even when services are not run by sysv, such as > checking processes by sending them some TCP bytes and analyze the answer. > > Adrien > Hi, Monit can work in systemd environment fine, you just need to use systemd's start/stop methods as Monit's start/stop program. You can then set Monit to check the process (including cpu usage, memory usage, network service test, etc.) and ask systemd to restart the process in case of failure (if Monit uses " ... then restart" action in the testing rule). Since Monit 5.7 there is also "restart" program, which is more straightforward then original restart=stop+start. Regards, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740803: [monit] sysvinit should move from recommends to suggests
On 05 Mar 2014, at 12:46, Sergey B Kirpichev wrote: > On Wed, Mar 05, 2014 at 11:35:49AM +0100, Martin Pala wrote: >> Monit can work in systemd environment fine, you just need to >> use systemd's start/stop methods as Monit's start/stop program. > > Yes, it can, if you are sure that your systemd's configuration > doesn't use any dangerous features of this bloatware. An example > was provided above (Restart option). If you find some features dangerous, please explain which and why? The restart of process via Monit (both old and new way) is exactly the same risk as restarting it via systemd. Monit makes sure that the process stops during the restart before starting it again. The fact that systemd starts the process instead of old init scripts doesn't matter - the way the process existence is checked prevents any problems. I'm not sure what you mean by bloatware ... Monit always was and will be opensource GPL application, there are years of hard work behind it. If you don't like it, don't use it, but please stop abusing for no reason. I appreciate your work as a package maintainer a lot, but if you feel that you don't want to maintain the package anymore, i can take the responsibility over. Regards, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740803: [monit] sysvinit should move from recommends to suggests
On 05 Mar 2014, at 16:06, Sergey B Kirpichev wrote: >> The restart of process via Monit (both old and new way) is exactly the same >> risk as restarting it via systemd. > > But what if your system was configured to restart some service *both* > with monit and systemd (this can be e.g. a default for this > particular service)? That's not a theory, it's a real-life case > for another distribution: > http://pkgs.fedoraproject.org/cgit/openssh.git/tree/sshd.service If the process existence is monitored by both Monit and systemd, then it's no problem as long as Monit uses systemd's start/stop methods - the process is managed only by systemd and Monit's restart request is processed by it. Systemd should handle the case where the process is restarting already and it receives restart request for the same process via CLI. It is also possible to suppress the "process existence" test in Monit configuration (Monit won't do any action) or set Monit to passive mode, in which case it won't perform the service restart. >> Monit always was and will be opensource GPL application, there are years >> of hard work behind it. If you don't like it, don't use it, >> but please stop abusing for no reason. > > Except for above misunderstanding, do you have any proofs of that > "abusing for no reason"? I'm sorry, i thought the "bloatware" note. Didn't knew you mean different application. > I don't like your CLA for same reason as > the Canonical CLA (btw, one reason why upstart now going to death). > But I'll send you any patches for Debian package, as long as submitter > is ok with your CLA. That is of course valid reason (CLA dislike). We don't force anybody to sign the CLA nor submit patches and understand if somebody doesn't want to submit patch under it. As mentioned we'll keep Monit opensource (GPL) and don't have any plans to close-source it. >> but if you >> feel that you don't want to maintain the package anymore, i can >> take the responsibility over. > > I want to maintain this package. But you are always welcomed > here - just ask for membership in > https://alioth.debian.org/projects/collab-maint/ > and then add something useful in the git repo. > > If you think that I'm not doing my job well - please > tell Debian QA team or release managers. In general, any DD > can revoke upload permissions for DM. I think you are great package maintainer - very pro-active and responsive. Kudos for you for your work. Regards, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740803: [monit] sysvinit should move from recommends to suggests
On 05 Mar 2014, at 22:07, Sergey B Kirpichev wrote: > On Wed, Mar 05, 2014 at 09:34:19PM +0100, Martin Pala wrote: >> If the process existence is monitored by both Monit and systemd, then it's no >> problem as long as Monit uses systemd's start/stop methods > > It's still racy. What if both systemd and monit decide to restart > the process? Suppose, that systemd do this first, process was restarted > and only then - monit request to restart arrive. Or, only systemd decide > to restart the service, and while it doing this - monit coming with test > to decide: bah, we should restart this service, it's dead... > > I think, it's a paintful idea to have two proactive monitoring > solutions to do the same job. Yes, the situation which you described may happen - systemd should be able to handle the case (abort the restart request if it's pending already or queue the second restart request - which makes less sense). I'm not sure if they implement it, but it may happen even without Monit asking systemd for process restart ... the user can do the same via CLI manually (let's say user does "restart process" twice ... while the first restart is pending, another restart request comes from user). In general you're right - it's not good practice to have two independent pro-active process checks ... however as mentioned, Monit can be configured to not act if process failed - it will still detect that the process crashed, but won't do any action. Monit's advantage are extended process test, such as per-process cpu usage, memory usage, protocol tests, etc. and it can supplement it to systemd environment. Regards, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#353758: monit: suboptimal logging reduces usefulness
Hello, the priority logging support was added to the monit cvs and will be part of next monit release (4.8) which will be released soon. Thanks, Martin Stefan Alfredsson wrote: Hello! Wouter Verhelst said: I'm attaching a quick-and-dirty patch which applies to monit-4.5 as it is in sarge, and which is the version that I'm currently using on this cluster. It's ugly, but it does what I needed it to do and was all I could come up with in the short timeframe that was given for this project. I know that's not very helpful; however, if upstream is interested, I'd be happy to help clean it up and provide a more robust method to differentiate log levels. I agree that log differentiation would be good, and judging from your patch, much needed :). I'm just about preparing monit 4.7, but the patch did not apply very cleanly (i.e. some 20 rejects), which means that new upstream versions probably also will need hands on fixing. I also noted that upstream is considering implementing this, which would be a much better solution. However, I think your patch is a good starting point, especially as much of the work involves determining the semantic of the log message (i.e. error, debug, etc). When the logging framework has been decided upon, it should be routine work (or even sed'able) to implement. Thanks, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364844: monit PID testing ignores "2 times within 5 cycles" syntax
Hi, fixed in monit cvs ... will be part of next monit release (4.8) which will be ready soon. Thanks for report, Martin root wrote: Package: monit Version: 1:4.7-1 Severity: important Monit's docs state: - PID TESTING monit tests the process id (pid) of processes for change. This test is implicit and monit will send alert in the case of failure by default. You may override the default action using below rule (it may only be used within a process service entry in the monit control file). The syntax for the pid statement is: IF CHANGED PID [[] CYCLES] THEN action action is a choice of ``ALERT'', ``RESTART'', ``START'', ``STOP'', ``EXEC'', ``MONITOR'' or ``UNMONITOR''. I have attempted many syntax variations of: if changed pid 2 times within 5 cycles then alert Yes in every case, Monit goes to alert status, and sends an email on every PID change. Above, in the Monit docs, one can see that you can change the default action by using the above syntax. This doesn't sem to be the case... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.13.4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages monit depends on: ii libc6 2.3.6-5GNU C Library: Shared libraries an ii libssl0.9.7 0.9.7e-3sarge1 SSL shared libraries -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367341: monit failed to restart after upgrade
Hi, this is AMD64 only related bug which is addressed by this patch for monit-4.8: http://www.tildeslash.com/monit/dist/monit-4.8-patch01 We will release monit-4.8.1 soon which will contain the fix. Martin Neil Broderick wrote: Package: monit Version: 1:4.8-1 Severity: grave Justification: renders package unusable Hi, I upgraded to the latest version of monit on the weekend with the following result: 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? y Setting up monit (4.8-1) ... Starting daemon monitor: monit/etc/init.d/monit: line 83: 13082 Segmentation fault start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON -- $ARGS >/dev/null 2>&1 invoke-rc.d: initscript monit, action "start" failed. dpkg: error processing monit (--configure): subprocess post-installation script returned error exit status 139 Errors were encountered while processing: monit E: Sub-process /usr/bin/dpkg returned an error code (1) Also trying to start monit manually results in: ruby:/home/ngb# monit Starting monit daemon with http interface at [*:2812] Segmentation fault or ruby:/home/ngb# /etc/init.d/monit start Starting daemon monitor: monit/etc/init.d/monit: line 83: 13088 Segmentation fault start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON -- $ARGS >/dev/null 2>&1 thanks, Neil -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-amd64-k8-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages monit depends on: ii libc6 2.3.6-5GNU C Library: Shared libraries an ii libssl0.9.8 0.9.8a-8 SSL shared libraries monit recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367341: [Fwd: Re: Bug#367341: monit failed to restart after upgrade]
Hi, monit-4.8.1 was released yesterday ... Martin Stefan Alfredsson wrote: (forwarding for reference. In summary - monit needs to be compiled on amd64 for the patch to be effective. It fails when started from initscripts but works with manual start -- I'll await 4.8.1 before doing further investigations) //Stefan Original Message Subject: Re: Bug#367341: monit failed to restart after upgrade From:"ngb" <[EMAIL PROTECTED]> Date:Wed, May 17, 2006 10:12 To: "Stefan Alfredsson" <[EMAIL PROTECTED]> -- Stefan, thanks for that. I have build the source without any trouble (although it did ask me to install byacc and cdbs which monit didn't need before). However when installing it I got the following: ruby:/home/ngb/monit# dpkg -i monit_4.8-2_amd64.deb (Reading database ... 163511 files and directories currently installed.) Preparing to replace monit 1:4.7-1 (using monit_4.8-2_amd64.deb) ... Stopping daemon monitor: monit. Unpacking replacement monit ... Setting up monit (4.8-2) ... Starting daemon monitor: monitinvoke-rc.d: initscript monit, action "start" failed. dpkg: error processing monit (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: monit However running "monit -d 240" from the command line started it with no problems. ruby:/home/ngb/monit# monit -d 240 Starting monit daemon with http interface at [*:2812] and I can log onto the web page and see that everything is working. thanks again for your help. cheers, Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306259: monit smtp check sends smtp commands without waiting for an answer
Hi, thanks for report, it was fixed in current cvs version and will be part of next monit version. Martin Tadas Zelionis wrote: Package: monit Version: 1:4.5-1 Severity: normal exim4 often gives this error, and then smpt check fails: SMTP protocol violation: synchronization error (input sent without waiting for greeting): rejected connection from H=localhost -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.29-srv10-x1-nohighmem Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages monit depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libssl0.9.7 0.9.7e-3 SSL shared libraries -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395164: Monit fails if log file is too large
Hi, there is support for large files (>2GB) in monit cvs already and it will be part of next monit version. Another solution which works even with current monit versions is to compile it with 64-bit support on platforms which supports it (the large files then aren't problem). Martin Thom May wrote: Package: monit Version: 1:4.8.1-2 Severity: grave Justification: renders package unusable When a file grows larger than 2GB, monit claims it no longer exists. This causes service failure actions to be executed, resulting in potential downtime or unecessary notification of downtime. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395164: Monit fails if log file is too large
I think it should be possible ... i've just resent the original patch which implemented the large files support (contributed by Will Bryant). We did some modifications for portability reasons during the integration, but it should work as is for linux. Cheers, Martin Stefan Alfredsson wrote: Hi, Martin Pala wrote: there is support for large files (>2GB) in monit cvs already and it will be part of next monit version. Would this be easy to backport to 4.8.1 or are there major changes involved? As we are nearing the next official debian release, I'm hesitant to include the cvs version, or a newly released version, given the "package duration"/"bug found" ratio of 4.8.1 :-), but a simple backport would be OK. Regards, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399027: Segfaults just after start
Hi,
i have tested it but i'm not able to reproduce the problem. Can you send
me your monit configuration and the state file?
Thanks,
Martin
Michal Čihař wrote:
Package: monit
Version: 1:4.8.1-2.1
Severity: important
Hi
I see this problem for more time, but didn't yet find time to report.
Monit segfaults for me just after startup. Here is end of strace:
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/var/lib/monit", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 7 entries */, 4096)= 240
write(2, "Processing postponed events queu"..., 34Processing postponed events
queue
) = 34
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 69, MSG_NOSIGNAL, NULL, 0) = 69
stat("/var/lib/monit/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/var/lib/monit/monit.state", {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
write(2, "monit: processing queued event /"..., 58monit: processing queued
event /var/lib/monit/monit.state
) = 58
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 93, MSG_NOSIGNAL, NULL, 0) = 93
open("/var/lib/monit/monit.state", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaae000
read(6, "\6\0\0\0lighttpd\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
1684
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 32479 detached
When I remove state file, it starts and seem to work fine (it didn't yet
run too long, but looks good enough so far). So there must be something
wrong with state saving/parsing. It fails whenever there is some state
file. I'm attaching one as example.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399027: Segfaults just after start
... looking on your trace in more detail i was able to reproduce the crash.
You have set the event queue directory and the state file to the same
directory:
set statefile /var/lib/monit/monit.state
set eventqueue basedir /var/lib/monit
This causes the crash, since monit tries to load on start all regular
files in the eventqueue directory and process it (including statefile).
The statefile has different format and causes the crash when enters the
queue processor.
There are two recommendations:
1.) don't set the statefile and eventqueue to the same directory (by
default monit statefile is create in the home directory, whereas the
eventqueue is in /var/monit)
2.) i will fix the event queue loader/processor to prevent the crash
when some file appears in the event queue which was not written by the
event queue writer / doesn't correspond to the event format.
Thanks for report :)
Martin
Michal Čihař wrote:
Package: monit
Version: 1:4.8.1-2.1
Severity: important
Hi
I see this problem for more time, but didn't yet find time to report.
Monit segfaults for me just after startup. Here is end of strace:
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/var/lib/monit", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 7 entries */, 4096)= 240
write(2, "Processing postponed events queu"..., 34Processing postponed events
queue
) = 34
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 69, MSG_NOSIGNAL, NULL, 0) = 69
stat("/var/lib/monit/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/var/lib/monit/monit.state", {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
write(2, "monit: processing queued event /"..., 58monit: processing queued
event /var/lib/monit/monit.state
) = 58
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 93, MSG_NOSIGNAL, NULL, 0) = 93
open("/var/lib/monit/monit.state", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaae000
read(6, "\6\0\0\0lighttpd\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
1684
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 32479 detached
When I remove state file, it starts and seem to work fine (it didn't yet
run too long, but looks good enough so far). So there must be something
wrong with state saving/parsing. It fails whenever there is some state
file. I'm attaching one as example.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399027: Segfaults just after start
Hi,
the patch which solves the problem is in the attachment (will be part of
next monit release).
Thanks,
Cheers,
Martin
Michal Čihař wrote:
Package: monit
Version: 1:4.8.1-2.1
Severity: important
Hi
I see this problem for more time, but didn't yet find time to report.
Monit segfaults for me just after startup. Here is end of strace:
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/var/lib/monit", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 7 entries */, 4096)= 240
write(2, "Processing postponed events queu"..., 34Processing postponed events
queue
) = 34
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 69, MSG_NOSIGNAL, NULL, 0) = 69
stat("/var/lib/monit/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/var/lib/monit/monit.state", {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
write(2, "monit: processing queued event /"..., 58monit: processing queued
event /var/lib/monit/monit.state
) = 58
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=806, ...}) = 0
sendto(4, "<31>Nov 17 09:20:47 monit[32479]"..., 93, MSG_NOSIGNAL, NULL, 0) = 93
open("/var/lib/monit/monit.state", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=1684, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaae000
read(6, "\6\0\0\0lighttpd\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
1684
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 32479 detached
When I remove state file, it starts and seem to work fine (it didn't yet
run too long, but looks good enough so far). So there must be something
wrong with state saving/parsing. It fails whenever there is some state
file. I'm attaching one as example.
Index: event.c
===
RCS file: /sources/monit/monit/event.c,v
retrieving revision 1.62
diff -u -r1.62 event.c
--- event.c 28 Jun 2006 09:02:43 - 1.62
+++ event.c 18 Nov 2006 00:13:50 -
@@ -564,39 +564,41 @@
{
LogError("%s: Processing failed - cannot open the event file %s --
%s\n",
prog, file_name, STRERROR);
-goto error;
+goto error1;
}
/* read event structure version */
- if(!(version = File_readQueue(file, &size)) || size != sizeof(int))
-goto error;
+ if(!(version = File_readQueue(file, &size)) || size != sizeof(int)) {
+LogError("skipping %s - unknown data format\n",
+ file_name, *version);
+goto error2;
+ }
if(*version != EVENT_VERSION)
{
LogError("Aborting event %s - incompatible data format version %d\n",
file_name, *version);
-unlink(file_name);
-goto error;
+goto error2;
}
/* read event structure */
if(!(e = File_readQueue(file, &size)) || size != sizeof(*e))
-goto error;
+goto error2;
/* read source */
if(!(e->source = File_readQueue(file, &size)))
-goto error;
+goto error3;
/* read group */
if(!(e->group = File_readQueue(file, &size)))
-goto error;
+goto error3;
/* read message */
if(!(e->message = File_readQueue(file, &size)))
-goto error;
+goto error3;
/* read event action */
if(!(action = File_readQueue(file, &size)) || size != sizeof(short))
-goto error;
+goto error3;
a->id = *action;
if(e->state == STATE_FAILED)
{
@@ -662,15 +664,17 @@
unlink(file_name);
}
- error:
- FREE(version);
- FREE(action);
+ error3:
FREE(e->source);
FREE(e->group);
FREE(e->message);
FREE(e);
+ FREE(action);
+ error2:
+ FREE(version);
fclose(file);
}
+error1:
de = readdir(dir);
}
Run.handler_init = FALSE;
Bug#399027: Segfaults just after start
Thanks for update :) The patch fixes the loader, so even common event queue and state or other file in /var/lib/monit/ directory will work (although i still recommend to set the event queue to other directory). Martin Michal Čihař wrote: Hi On Sat, 18 Nov 2006 00:44:23 +0100 Martin Pala <[EMAIL PROTECTED]> wrote: ... looking on your trace in more detail i was able to reproduce the crash. You have set the event queue directory and the state file to the same directory: set statefile /var/lib/monit/monit.state set eventqueue basedir /var/lib/monit I have only eventqueue set, I don't have statefile settings in config file. The state file is set to this path using command line argument in debian init script... 1.) don't set the statefile and eventqueue to the same directory (by default monit statefile is create in the home directory, whereas the eventqueue is in /var/monit) The statefile default is not true for Debian package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
