I did all but I did not solve the problem so I will better investigate alternative causes.
I suppose something went wrong when SA tries to load the plugin (by accessing clamav.cf and/or clamav.pm) during the startup process only. At this point probably is not a time-related issue. Thank you Harald. —Carlo > On 08 Jun 2016, at 13:56, Reindl Harald <h.rei...@thelounge.net> wrote: > > > > Am 08.06.2016 um 13:49 schrieb Carlo Manuali: >> I wrote a init-script as follows (S20clamd followed by other services >> then S78SpamAssassin) but nothing has changed (in the meantime all the >> daemons and services are up and running). >> >> On top of all, just re-running "/etc/init.d/SpamAssassin restart" from >> shell the system starts working. >> >> Any other idea? > > i would say "/usr/local/sbin/clamd" is plain wrong and don't lead in the > expected double-fork behavior > > "daemon /usr/local/sbin/clamd" likely works better > > https://wiki.mattrude.com/ClamAV#ClamAV_INIT_Script > daemon $prefix/sbin/clamd > ____________________________________ > > no idea what in fact goes wrong because i can do a "systemctl restart > clamd-sa" at every moment in time while SA is already runnign since SA is > just supposed to connect again to the socket and not have a permanent > connection at all > > so it should be anyways only a temorary problem and SA is also supposed to > handle that because when clamd reloads it's signatures due updates it also > don't respond which leads in case of clamav-milter in a temporary reject on > the postfix side > > >> # cat S20clamd >> #!/bin/sh >> # >> # description: ClamAV daemon >> # >> # Get function from functions library >> . /etc/init.d/functions >> start() { >> echo -n $"Starting clamd: " >> /usr/local/sbin/clamd >> touch /var/lock/subsys/clamd >> success $”ClamAV daemon startup" >> echo >> } >> stop() { >> echo -n $"Stopping clamd: " >> killproc clamd >> rm -f /var/lock/subsys/clamd >> echo >> } >> case "$1" in >> start) >> start >> ;; >> stop) >> stop >> ;; >> status) >> status clamd >> ;; >> restart) >> stop >> start >> ;; >> *) >> echo $"Usage: $0 {start|stop|restart}" >> exit 1 >> esac >> exit 0 >> >> >>> On 08 Jun 2016, at 13:19, Reindl Harald <h.rei...@thelounge.net >>> <mailto:h.rei...@thelounge.net>> wrote: >>> >>> >>> >>> Am 08.06.2016 um 12:58 schrieb Carlo Manuali: >>>> yes, 6.7. >>>> >>>> I totally agree with you, but unfortunately I can’t change a system >>>> in production now. >>>> >>>> Any other ideas? >>> >>> try to implement something like >>> "ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID" in the >>> mysqld-unit after starting clamd, in fact it tests if mysqld is ready >>> to accept connections >>> >>> get rid of rc.local >>> >>> /etc/rc3.d/ has numbers in the filenames for ordering >>> >>> so you need a service between clamd and spamassassin which holds as >>> long as clamd is not ready >>> >>> "/usr/local/sbin/clamd && /etc/init.d/spamassassin restart" in >>> "rc.local" can not work because at that moment spamassassin is already >>> running too soon - you need *at least* a init-script for clamd with a >>> correct ordering at boot >>> >>> http://www.cyberciti.biz/tips/linux-write-sys-v-init-script-to-start-stop-service.html >>> ________________________________________ >>> >>> [root@srv-rhsoft:~]$ cat /usr/libexec/mysqld-wait-ready >>> #!/usr/bin/bash >>> >>> # Service file passes us the daemon's PID >>> daemon_pid="$1" >>> >>> # Wait for the server to come up or for the mysqld process to disappear >>> ret=0 >>> while /usr/bin/true; do >>> RESPONSE=`/usr/bin/mysqladmin --defaults-file=/etc/my.cnf >>> --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping 2>&1` >>> mret=$? >>> if [ $mret -eq 0 ]; then >>> break >>> fi >>> # exit codes 1, 11 (EXIT_CANNOT_CONNECT_TO_SERVICE) are expected, >>> # anything else suggests a configuration error >>> if [ $mret -ne 1 -a $mret -ne 11 ]; then >>> ret=1 >>> break >>> fi >>> # "Access denied" also means the server is alive >>> echo "$RESPONSE" | grep -q "Access denied for user" && break >>> >>> # Check process still exists >>> if ! /usr/bin/kill -0 $daemon_pid 2>/dev/null; then >>> ret=1 >>> break >>> fi >>> usleep 100000 >>> done >>> >>> exit $ret >>> ________________________________________ >>> >>> >>>>> On 08 Jun 2016, at 12:53, Reindl Harald <h.rei...@thelounge.net> wrote: >>>>> >>>>> >>>>> >>>>> Am 08.06.2016 um 12:33 schrieb Carlo Manuali: >>>>>> yes, I’m using scientific linux, fedora/redhat in other words. I >>>>>> also tried: >>>>> >>>>> which version - sounds like 6 or older when someone is talking about >>>>> /etc/init.d/ >>>>> >>>>>> /usr/local/sbin/clamd && /etc/init.d/spamassassin restart >>>>>> >>>>>> in rc.local (-> S99local in /etc/rc3.d/ )with no success. >>>>> >>>>> get SL7.0 which comes with systemd and i can assure you >>>>> systemd.units with correctsAfter/Before statements and clamd as >>>>> "Type=forking" works with a perfectly start ordering >>>>> >>>>> when "rc.local" is the answer then the question was typically wrong >>>>> >>>>>>> On 08 Jun 2016, at 12:11, Reindl Harald <h.rei...@thelounge.net >>>>>>> <mailto:h.rei...@thelounge.net>> wrote: >>>>>>> >>>>>>> Am 08.06.2016 um 12:02 schrieb Carlo Manuali: >>>>>>>> I’ve installed the ClamAV plugin (v1.93, with v0.99.2 as ClamAV >>>>>>>> engine) according to: >>>>>>>> https://wiki.apache.org/spamassassin/ClamAVPlugin. All has gone well, >>>>>>>> it works. >>>>>>>> >>>>>>>> In particular I’ve adopted the local mode, that uses a local socket >>>>>>>> (file) in order to establish the communication between them. >>>>>>>> >>>>>>>> Now, I need to put both (clamd -the daemon- and the SpamAssassin >>>>>>>> service) starting at boot, keeping in mind, of course, that >>>>>>>> SpamAssassin needs clamd to be up un running in order to load the >>>>>>>> related plugin. So: >>>>>>>> >>>>>>>> - I tried to put clamd on rc.local then moving SpamAssassin after: >>>>>>>> all the services started but the plugin do not "attach the daemon” >>>>>>>> (no filtering viruses); >>>>>>>> - I tried to put clamd followed by a ‘SpamAssassin restart' on >>>>>>>> rc.local: the same, all seems ok but no success. >>>>>>>> >>>>>>>> Only when I restart SpamAssassin manually from a shell (with the >>>>>>>> clamd started) all goes well. As a matter of fact, I receive on the >>>>>>>> clamd logfile the message: >>>>>>>> >>>>>>>> stream(127.0.0.1@1858): OK. >>>>>>>> >>>>>>>> Then the filtering is ok. >>>>>>>> >>>>>>>> Any idea on how to proceed? >>>>>>> >>>>>>> "clamd" needs a relatve long time to start because reading and verify >>>>>>> signatures (no sleep 15 is not a solution, it only masks the problem) >>>>>>> >>>>>>> so it needs to be "Type=forking" instead "Type=simple" (the Fedora >>>>>>> systemd-units are plain wrong) to make the ordering really working >>>>>>> >>>>>>> no idea how to do this *sane* on a non systemd-os since i did not >>>>>>> touch such setups the last 5 years and now after even Debian >>>>>>> switches.... >>>>>>> >>>>>>> see systemd-analyze at bottom >>>>>>> ____________________________________________ >>>>>>> >>>>>>> [root@mail-gw:~]$ cat /etc/systemd/system/clamd-sa.service >>>>>>> [Unit] >>>>>>> Description=ClamAV Scanner Daemon for SpamAssassin >>>>>>> Before=spamassassin.service >>>>>>> >>>>>>> [Service] >>>>>>> Type=forking >>>>>>> Environment="TMPDIR=/tmp" >>>>>>> Environment="LANG=en_GB.UTF-8" >>>>>>> ExecStart=/usr/sbin/clamd -c /etc/clamd.d/scan-sa.conf >>>>>>> ExecReload=/usr/bin/kill -SIGUSR2 $MAINPID >>>>>>> Restart=always >>>>>>> RestartSec=1 >>>>>>> User=clamscan >>>>>>> Group=clamilt >>>>>>> PrivateTmp=yes >>>>>>> PrivateDevices=yes >>>>>>> NoNewPrivileges=yes >>>>>>> CapabilityBoundingSet=CAP_KILL >>>>>>> ReadOnlyDirectories=/etc >>>>>>> ReadOnlyDirectories=/usr >>>>>>> ReadOnlyDirectories=/var/lib >>>>>>> ____________________________________________ >>>>>>> >>>>>>> >>>>>>> [root@mail-gw:~]$ systemd-analyze >>>>>>> Startup finished in 366ms (kernel) + 539ms (initrd) + 8.907s >>>>>>> (userspace) = 9.813s >>>>>>> >>>>>>> [root@mail-gw:~]$ systemd-analyze blame >>>>>>> 6.882s clamd.service >>>>>>> 6.313s clamd-sa.service >>>>>>> 3.250s sa-update.service >>>>>>> 1.194s bayes.service >>>>>>> 527ms postfix.service >>>>>>> 420ms network.service >>>>>>> 361ms spamassassin.service >>>>>>> 281ms mailgraph.service >>>>>>> 245ms dev-sdb1.device >>>>>>> 205ms iptables.service > ______________________________________________________________________ Dr. Carlo Manuali Responsabile Servizi Informatici / IT Services Manager Department of Chemistry, Biology and Biotechnology - University of Perugia (IT) Mail: carlo.manu...@unipg.it Web: http://www.unipg.it/carlo Office: +39.075.5855213 ______________________________________________________________________
