Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
Hello Andreas, On Wed, May 21, 2014 at 10:16 PM, Andreas Cadhalpun wrote: > On 20.05.2014 12:07, Peter Gervai wrote: > The exit codes should now be LSB compliant, see [1]. > I hope that suits your needs. Sounds great. It's technically not "my" needs (I have patched it already) but everyone who should depend on LSB behaviour. Thanks! >> I am not sure why there's supervision support in the init.d script, > The supervision is enforced, because otherwise the init script would never > finish if clamd is started in foreground mode. You're right (that's one way to handle it). Thanks. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
Hi Peter, On 20.05.2014 12:07, Peter Gervai wrote: On Tue, May 20, 2014 at 12:01 AM, Andreas Cadhalpun wrote: http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html Do I understand you correctly that you want the return codes to be changed? Consistent exit codes are one thing possibly helping world peace, yes. The exit codes should now be LSB compliant, see [1]. I hope that suits your needs. I am not sure why there's supervision support in the init.d script, and even if so, why is it so aggressively enforced. True, I'm using a custom runit supervision script and not the init.d script but I don't really see the reasons being mentioned in the README.Debian, so users may find it only by pure luck. :-) The supervision is enforced, because otherwise the init script would never finish if clamd is started in foreground mode. Best regards, Andreas 1: http://anonscm.debian.org/gitweb/?p=pkg-clamav/clamav.git;a=commitdiff;h=1dc9eaa7a8179b1e726b85bf1a524d7a110cf64f -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
On Tue, May 20, 2014 at 12:01 AM, Andreas Cadhalpun wrote: >> http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html > > Do I understand you correctly that you want the return codes to be changed? Consistent exit codes are one thing possibly helping world peace, yes. I am not sure why there's supervision support in the init.d script, and even if so, why is it so aggressively enforced. True, I'm using a custom runit supervision script and not the init.d script but I don't really see the reasons being mentioned in the README.Debian, so users may find it only by pure luck. :-) peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
Control: tags -1 -moreinfo Control: tags -1 pending Hi Peter, On 19.05.2014 21:29, Peter Gervai wrote: On Mon, May 19, 2014 at 7:19 PM, Andreas Cadhalpun wrote: Why should this be necessary? CLAMAVCONF=/etc/clamav/clamd.conf is the default location, where clamd looks for a configuration file. Or did you change CLAMAVCONF and if so, why? Obviously. :-) The machine is part of a cluster and the cluster have more than one moving clamav server instances. If there's a problem with a clamav-hosting cluster member its clamav (along with its IP and config) moves over to the other cluster hosts, so it's possible that one host runs more than one clamav (on different IP addresses). Due to pid and locking issues (and some generalisations) it's much easier to have multiple configs than trying to manually set various parameters. But if you look at your script it partially written as being able to use any config file so the careless reader (like I was) would think it will work for other config names, which isn't true. You could, obviously, remove any variables containing the config file but my suggestion may be more useful for the general happiness of the sysadmins. Now I see. I think the intention of the $CLAMAVCONF variable was, to make it easy to adapt the script, when the default location of the configuration file changes. But since the change you proposed doesn't do any harm and apparently has a usecase, I commited it to the repo [1]. Apart from that it isn't quite LSBish that the initscript bails out when config is set to foreground and there's no 'daemon' installed, even on help or status requests. It's pretty impolite towards a clusering infrastructure for example. I'm not aware of any 'help' request that the init script should handle, and for the status request, the error message gives the status, i.e. that there is a configuration problem. Or what status message would you expect in that case? Basically http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html Do I understand you correctly that you want the return codes to be changed? Best regards, Andreas 1: http://anonscm.debian.org/gitweb/?p=pkg-clamav/clamav.git;a=commitdiff;h=0397b225698b31ca80ed123fc636661f949f4528 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
On Mon, May 19, 2014 at 7:19 PM, Andreas Cadhalpun wrote: > Why should this be necessary? > CLAMAVCONF=/etc/clamav/clamd.conf is the default location, where clamd looks > for a configuration file. Or did you change CLAMAVCONF and if so, why? Obviously. :-) The machine is part of a cluster and the cluster have more than one moving clamav server instances. If there's a problem with a clamav-hosting cluster member its clamav (along with its IP and config) moves over to the other cluster hosts, so it's possible that one host runs more than one clamav (on different IP addresses). Due to pid and locking issues (and some generalisations) it's much easier to have multiple configs than trying to manually set various parameters. But if you look at your script it partially written as being able to use any config file so the careless reader (like I was) would think it will work for other config names, which isn't true. You could, obviously, remove any variables containing the config file but my suggestion may be more useful for the general happiness of the sysadmins. >> Apart from that it isn't quite LSBish that the initscript bails out >> when config is >> set to foreground and there's no 'daemon' installed, even on help or >> status >> requests. It's pretty impolite towards a clusering infrastructure for >> example. > > > I'm not aware of any 'help' request that the init script should handle, and > for the status request, the error message gives the status, i.e. that there > is a configuration problem. > > Or what status message would you expect in that case? Basically http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-lsb.html Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
Control: tags -1 moreinfo Hi Peter, On 16.05.2014 02:22, Peter Gervai wrote: Package: clamav-daemon Version: 0.98.1+dfsg-5 Severity: normal --- /etc/init.d/clamav-daemon 2014-04-24 08:13:03.0 +0200 +++ /etc/init.d/clamd2 2014-05-16 02:15:17.939141376 +0200 @@ -320,7 +320,7 @@ done if [ -z "$RUN_SUPERVISED" ] ; then log_daemon_msg "Starting $DESC" "$NAME " -start-stop-daemon --start --oknodo -c $User --exec $DAEMON --pidfile $THEPIDFILE +start-stop-daemon --start --oknodo -c $User --exec $DAEMON --pidfile $THEPIDFILE -- -c $CLAMAVCONF ret=$? else log_daemon_msg "Starting $DESC" "$NAME (supervised) " Why should this be necessary? CLAMAVCONF=/etc/clamav/clamd.conf is the default location, where clamd looks for a configuration file. Or did you change CLAMAVCONF and if so, why? Apart from that it isn't quite LSBish that the initscript bails out when config is set to foreground and there's no 'daemon' installed, even on help or status requests. It's pretty impolite towards a clusering infrastructure for example. I'm not aware of any 'help' request that the init script should handle, and for the status request, the error message gives the status, i.e. that there is a configuration problem. Or what status message would you expect in that case? Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748310: clamav-daemon: initscript ignores configfile name at daemon start
Package: clamav-daemon Version: 0.98.1+dfsg-5 Severity: normal --- /etc/init.d/clamav-daemon 2014-04-24 08:13:03.0 +0200 +++ /etc/init.d/clamd2 2014-05-16 02:15:17.939141376 +0200 @@ -320,7 +320,7 @@ done if [ -z "$RUN_SUPERVISED" ] ; then log_daemon_msg "Starting $DESC" "$NAME " -start-stop-daemon --start --oknodo -c $User --exec $DAEMON --pidfile $THEPIDFILE +start-stop-daemon --start --oknodo -c $User --exec $DAEMON --pidfile $THEPIDFILE -- -c $CLAMAVCONF ret=$? else log_daemon_msg "Starting $DESC" "$NAME (supervised) " Apart from that it isn't quite LSBish that the initscript bails out when config is set to foreground and there's no 'daemon' installed, even on help or status requests. It's pretty impolite towards a clusering infrastructure for example. thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
