On Fri, 21 Aug 2020, Michael Orlitzky via clamav-users wrote: > Date: Fri, 21 Aug 2020 10:18:42 -0400 > From: Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net> > To: clamav-users@lists.clamav.net > Cc: Michael Orlitzky <mich...@orlitzky.com> > Subject: Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd > service start fails > > On 2020-08-21 09:38, Arjen de Korte via clamav-users wrote: > >> > >> However, systemd isn't the only service manager, and the problem still > >> exists in all of the other ones. Systemd is able to avail itself of > >> platform-specific features in brand-new Linux kernels. SysV init, > >> OpenRC, and others must stick to real or de-facto standard tools, and > >> there is no standard way to implement what systemd says they've done. > > > > That may be, but now you have replaced it with two processes that run > > in the foreground, one of them as unpriviledged user and one as root > > (probably to delete the PIDFile upon exit). I don't consider this > > progress. > > > > The clamd process starts in the foreground, and then forks (a new > process) to the background. The PID file should contain the PID of the > forked process. No root process should be left running in the > foreground; the service manager is in charge of cleaning up the file. > > > >> > >> That's fine, now you just need to synchronize the PIDFile and PidFile > >> entries in your systemd service and clamd.conf, respectively. > > > > No, as stated before, systemd doesn't need the PIDFile at all. It > > keeps track of the processes it started without the help of a PIDFile. > > It *can* use a PIDFile if you provide it with one and the only thing > > it will do with that is to remove that file if the service doesn't do > > it itself upon exit. Nothing more, it is not used for process control. > > There is absolutely no need for a PIDFile in the clamd.service, even > > with Type=forking. > > Systemd tries to guess the PID file with Type=forking when you don't > provide one (the GuessMainPID option). Either way, systemd does need to > know the PID file's location -- the only question is whether or not it's > able to guess. Something isn't working, so to rule some things out, it > might help to point it at the PID file manually. > > > >> Well empirically that's not true, because it isn't working. Add PIDFile > >> entries to your service files when using Type=forking, and synchronize > >> them with the PidFile lines in clamd.conf and freshclam.conf. > > > > Makes no difference at all. Even without using systemd, clamd doesn't > > daemonize anymore, it will always run in the foreground. > > How long have you waited for clamd to start? With git head (and only > official signatures), it takes about 25 seconds here: > > # time sbin/clamd > > real 0m25.409s > user 0m0.005s > sys 0m0.005s > > but after that the process does indeed fork into the background. If it > doesn't, maybe we're looking in the wrong place. The PID file also > points to the correct (forked) process in my case: > > # cat run/clamd.pid > 7436 > # ps ax | grep clamd > 7436 ? Ssl 0:25 sbin/clamd > [hubble:root]:(~)# service clamd stop Stopping Clam AntiVirus Daemon: [ OK ] [hubble:root]:(~)# time service clamd start Starting Clam AntiVirus Daemon: [ OK ] 30.00user 2.06system 0:32.07elapsed 99%CPU (0avgtext+0avgdata 4311168maxresident)k 0inputs+0outputs (0major+500027minor)pagefaults 0swaps [hubble:root]:(~)# clamdscan --version ClamAV 0.102.4/25906/Fri Aug 21 15:10:42 2020 [hubble:root]:(~)# cat /var/lib/run/clamav/clamd.pid 32185 [hubble:root]:(~)# ps ax | grep clamd 32185 ? Ssl 0:00 clamd 32344 pts/2 S+ 0:00 grep --color clamd [hubble:stock]:(~)# rpm -q -f /sbin/init SysVinit-2.86-4mdk [hubble:stock]:(~)#
-- Robert M. Stockmann - RHCE Network Engineer - UNIX/Linux Specialist crashrecovery.org st...@stokkie.net _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
