[clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
OS: openSUSE Tumbleweed I have found (like others) that the ClamAV 0.103.0-rc service doesn't start. When running the binary in a console, it doesn't daemonize, but keeps running. PID file and socket are created however. I bisected this problem and found the commit bb12435: Create PID file before dropping privileges. to be the culprit here. Reverting that one, all is well. It is not clear to me what problem this patch intends to solve (for a systemd service it is absolute not required from a security point of view). The PIDFile should be writable by vscan user only anyway. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
Citeren Arjen de Korte via clamav-users : OS: openSUSE Tumbleweed I have found (like others) that the ClamAV 0.103.0-rc service doesn't start. When running the binary in a console, it doesn't daemonize, but keeps running. PID file and socket are created however. That should have read the clamd.service and the /usr/sbin/clamd binary respectively. I bisected this problem and found the commit bb12435: Create PID file before dropping privileges. to be the culprit here. Reverting that one, all is well. It is not clear to me what problem this patch intends to solve (for a systemd service it is absolute not required from a security point of view). The PIDFile should be writable by vscan user only anyway. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote: > > It is not clear to me what problem this patch intends to solve (for a > systemd service it is absolute not required from a security point of > view). The PIDFile should be writable by vscan user only anyway. > With a Type=forking service, systemd will send SIGTERM to the contents of the PID file as root. If the "vscan" user can put whatever he wants in the PID file, then he can kill root processes. Are you using the upstream systemd service? It defaults to Type=simple, and runs clamd in the foreground. In that case, your clamd daemon shouldn't be creating a PID file at all -- systemd should take care of it when it shoves the process into the background. PidFile should be left unset in clamd.conf. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
Citeren Michael Orlitzky via clamav-users : On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote: It is not clear to me what problem this patch intends to solve (for a systemd service it is absolute not required from a security point of view). The PIDFile should be writable by vscan user only anyway. With a Type=forking service, systemd will send SIGTERM to the contents of the PID file as root. Not unconditionally. See the following from 'man 5 systemd.service': "The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service." If the "vscan" user can put whatever he wants in the PID file, then he can kill root processes. See above: you're trying to fix a problem that doesn't exist. Are you using the upstream systemd service? No, we're using "Type=forking" since the clamd.service can take several minutes to start and we don't want to start services that depend on it before it actually finished starting up. Creating the socket beforehand is not a solution, as clamd won't start serving any requests until it has actually finished starting up. It defaults to Type=simple, and runs clamd in the foreground. See above. Actually, with this patch clamd wil always run in the foreground, as daemonizing is now completely broken. Up to and including 0.102.4, starting clamd on the commandline without any further options would just start the daemon and return. Now, it never returns. In that case, your clamd daemon shouldn't be creating a PID file at all -- systemd should take care of it when it shoves the process into the background. PidFile should be left unset in clamd.conf. There is no PIDFile in the clamd.service file as systemd doesn't need that here (even when running as Type=forking). The same goes for freshclam.service. Systemd has other ways to keep track of which processes it has started and will not use the PIDFile unless you tell it to do so (with the above mentioned restrictions). ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote: > Citeren Michael Orlitzky via clamav-users : > >> On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote: >>> >>> It is not clear to me what problem this patch intends to solve (for a >>> systemd service it is absolute not required from a security point of >>> view). The PIDFile should be writable by vscan user only anyway. >>> >> >> With a Type=forking service, systemd will send SIGTERM to the contents >> of the PID file as root. > > Not unconditionally. See the following from 'man 5 systemd.service': > > "The PID file does not need to be owned by a privileged user, but if it > is owned by an unprivileged user additional safety restrictions are > enforced: the file may not be a symlink to a file owned by a different > user (neither directly nor indirectly), and the PID file must refer to > a process already belonging to the service." > That's good to hear (and is news to me), and maybe they've found another way to prevent this vulnerability in systemd. >> If the "vscan" user can put whatever he wants >> in the PID file, then he can kill root processes. > > See above: you're trying to fix a problem that doesn't exist. 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. >> Are you using the upstream systemd service? > > No, we're using "Type=forking" since the clamd.service can take > several minutes to start and we don't want to start services that > depend on it before it actually finished starting up. Creating the > socket beforehand is not a solution, as clamd won't start serving any > requests until it has actually finished starting up. That's fine, now you just need to synchronize the PIDFile and PidFile entries in your systemd service and clamd.conf, respectively. I suggest /run/clamd.pid, or any other location that is writable only by root. >> It defaults to Type=simple, and runs clamd in the foreground. > > See above. Actually, with this patch clamd wil always run in the > foreground, as daemonizing is now completely broken. Up to and > including 0.102.4, starting clamd on the commandline without any > further options would just start the daemon and return. Now, it never > returns. That's not true, your service file just needs to know where the PID file lives. It always did, but somehow it managed to not crash in the past. >> In that case, your clamd daemon >> shouldn't be creating a PID file at all -- systemd should take care of >> it when it shoves the process into the background. PidFile should be >> left unset in clamd.conf. > > There is no PIDFile in the clamd.service file as systemd doesn't need > that here (even when running as Type=forking). The same goes for > freshclam.service. Systemd has other ways to keep track of which > processes it has started and will not use the PIDFile unless you tell > it to do so (with the above mentioned restrictions). 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. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote: > > Not unconditionally. See the following from 'man 5 systemd.service': > > "The PID file does not need to be owned by a privileged user, but if it > is owned by an unprivileged user additional safety restrictions are > enforced: the file may not be a symlink to a file owned by a different > user (neither directly nor indirectly), and the PID file must refer to > a process already belonging to the service." > FWIW this was committed on Jan 8th 2018, and solves the problem by keeping a separate pid <-> process <-> service map that's writable only by root. The patch in question provides the same security to other service managers. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
Citeren Michael Orlitzky via clamav-users : On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote: Citeren Michael Orlitzky via clamav-users : On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote: It is not clear to me what problem this patch intends to solve (for a systemd service it is absolute not required from a security point of view). The PIDFile should be writable by vscan user only anyway. With a Type=forking service, systemd will send SIGTERM to the contents of the PID file as root. Not unconditionally. See the following from 'man 5 systemd.service': "The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service." That's good to hear (and is news to me), and maybe they've found another way to prevent this vulnerability in systemd. If the "vscan" user can put whatever he wants in the PID file, then he can kill root processes. See above: you're trying to fix a problem that doesn't exist. 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. Are you using the upstream systemd service? No, we're using "Type=forking" since the clamd.service can take several minutes to start and we don't want to start services that depend on it before it actually finished starting up. Creating the socket beforehand is not a solution, as clamd won't start serving any requests until it has actually finished starting up. 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. I suggest /run/clamd.pid, or any other location that is writable only by root. It's fine where it is now. See above: systemd doesn't care. It defaults to Type=simple, and runs clamd in the foreground. See above. Actually, with this patch clamd wil always run in the foreground, as daemonizing is now completely broken. Up to and including 0.102.4, starting clamd on the commandline without any further options would just start the daemon and return. Now, it never returns. That's not true, your service file just needs to know where the PID file lives. It always did, but somehow it managed to not crash in the past. No, it doesn't, see above. Even if I start clamd on the commandline (which should then daemonize, unless told by --foreground to stay in the foreground) without any of this. This is a regression and has nothing to do with systemd. In that case, your clamd daemon shouldn't be creating a PID file at all -- systemd should take care of it when it shoves the process into the background. PidFile should be left unset in clamd.conf. There is no PIDFile in the clamd.service file as systemd doesn't need that here (even when running as Type=forking). The same goes for freshclam.service. Systemd has other ways to keep track of which processes it has started and will not use the PIDFile unless you tell it to do so (with the above mentioned restrictions). 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. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
Citeren Michael Orlitzky via clamav-users : On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote: Not unconditionally. See the following from 'man 5 systemd.service': "The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service." FWIW this was committed on Jan 8th 2018, and solves the problem by keeping a separate pid <-> process <-> service map that's writable only by root. The patch in question provides the same security to other service managers. Great, but what happened to daemonizing clamd? ___ 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
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 ?Ssl0:25 sbin/clamd ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
Citeren Michael Orlitzky via clamav-users : 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 Loading takes a similar amount of time here, from the time starting '/usr/sbin/clamd --debug' to the moment the line aug 21 17:14:12 orthros clamd[7841]: Self checking every 600 seconds. is logged. 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 In a different command window: # cat /run/clamav/clamd.pid 7841 So the PID file seems to contain the correct information # ps ax | grep clamd 7436 ?Ssl0:25 sbin/clamd # ps ax | grep clamd 7840 pts/2S+ 0:00 /usr/sbin/clamd --debug 7841 ?Ssl0:38 /usr/sbin/clamd --debug Previously I've waited for more than an hour, no change. The process running under root never exits. ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
On 2020-08-21 11:29, Arjen de Korte via clamav-users wrote: > >> # ps ax | grep clamd >> 7436 ?Ssl0:25 sbin/clamd > > # ps ax | grep clamd > 7840 pts/2S+ 0:00 /usr/sbin/clamd --debug > 7841 ?Ssl0:38 /usr/sbin/clamd --debug > > Previously I've waited for more than an hour, no change. The process > running under root never exits. > Ok, I can confirm this! After setting User clamav in clamd.conf, I've seen the root process get stuck as well. That's not an intended effect of the PID file change. ___ 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
Re: [clamav-users] on-access scan /media folder
Hi there, Sorry again for the delay. I've attached a small patch which provides a bit deeper (and possibly excessive) error reporting for clamonacc. Please give it a try and let us know what errors pop up so we can better figure out the problem. Thanks, Mickey On 2020-08-17 18:41:49-04:00 clamav-users wrote: Sorry for the long delay on my part as well. My teammate Mickey is presently working on a patch to improve the error output to so we can get a better idea what’s gone wrong for you. She or I will let you know as soon as we have something that you can test with. Regards, Micah From: clamav-users On Behalf Of Marian Galbavy via clamav-users Sent: Wednesday, August 12, 2020 12:57 AM To: ClamAV users ML Cc: Marian Galbavy Subject: Re: [clamav-users] on-access scan /media folder Thank you guys for your answers. Sorry for my late reply, I was in abroad. I have already read documentation of ClamAV, but I didn't find any answer, what does error 3 mean. Here is my clamd.conf: #Automatically Generated by clamav-daemon postinst #To reconfigure clamd run #dpkg-reconfigure clamav-daemon #Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details LocalSocket /var/run/clamav/clamd.ctl FixStaleSocket true LocalSocketGroup clamav LocalSocketMode 666 # TemporaryDirectory is not set to its default /tmp here to make overriding # the default with environment variables TMPDIR/TMP/TEMP possible User clamav ScanMail true ScanArchive true ArchiveBlockEncrypted false MaxDirectoryRecursion 15 FollowDirectorySymlinks false FollowFileSymlinks false ReadTimeout 180 MaxThreads 12 MaxConnectionQueueLength 15 LogSyslog false LogRotate true LogFacility LOG_LOCAL6 LogClean false LogVerbose false PreludeEnable no PreludeAnalyzerName ClamAV DatabaseDirectory /var/lib/clamav OfficialDatabaseOnly false SelfCheck 3600 Foreground false Debug false ScanPE true MaxEmbeddedPE 10M ScanOLE2 true ScanPDF true ScanHTML true MaxHTMLNormalize 10M MaxHTMLNoTags 2M MaxScriptNormalize 5M MaxZipTypeRcg 1M ScanSWF true ExitOnOOM false LeaveTemporaryFiles false AlgorithmicDetection true ScanELF true IdleTimeout 30 CrossFilesystems true PhishingSignatures true PhishingScanURLs true PhishingAlwaysBlockSSLMismatch false PhishingAlwaysBlockCloak false PartitionIntersection false DetectPUA false ScanPartialMessages false HeuristicScanPrecedence false StructuredDataDetection false CommandReadTimeout 30 SendBufTimeout 200 MaxQueue 100 ExtendedDetectionInfo true OLE2BlockMacros false AllowAllMatchScan true ForceToDisk false DisableCertCheck false DisableCache false MaxScanTime 12 MaxScanSize 100M MaxFileSize 25M MaxRecursion 16 MaxFiles 1 MaxPartitions 50 MaxIconsPE 100 PCREMatchLimit 1 PCRERecMatchLimit 5000 PCREMaxFileSize 25M ScanXMLDOCS true ScanHWP3 true MaxRecHWP3 16 StreamMaxLength 25M LogFile /var/log/clamav/clamav.log LogTime true LogFileUnlock false LogFileMaxSize 0 Bytecode true BytecodeSecurity TrustSigned BytecodeTimeout 6 OnAccessMaxFileSize 5M OnAccessPrevention yes OnAccessIncludePath /home OnAccessIncludePath /usr/local OnAccessIncludePath /tmp OnAccessIncludePath /var OnAccessIncludePath /opt OnAccessIncludePath /root OnAccessExcludeUname clamav OnAccessDisableDDD no Micah, sounds great, if you will make some patch, I am able to test it. Thank you in advance :) st 5. 8. 2020 o 22:06 Micah Snyder (micasnyd) via clamav-users mailto:clamav-users@lists.clamav.net>> napísal(a): Hi Marian, To add to what Ged said -- Mickey is actively investigating the source of the error you've described. Unfortunately the errors currently produced when watching a mount point fails do not provide very much detail about why it failed. If we create a patch, would you be able to compile and test with the patch to help us figure out what is causing the issue you've encountered? Regards, Micah -Original Message- From: clamav-users mailto:clamav-users-boun...@lists.clamav.net>> On Behalf Of G.W. Haywood via clamav-users Sent: Tuesday, August 4, 2020 5:16 AM To: Marian Galbavy via clamav-users mailto:clamav-users@lists.clamav.net>> Cc: G.W. Haywood mailto:cla...@jubileegroup.co.uk>> Subject: Re: [clamav-users] on-access scan /media folder Hi there, On Tue, 4 Aug 2020, Marian Galbavy via clamav-users wrote: > I have problem with on-access scan of /media folder in Ubuntu. I would > like to have on-access scan for connected removable devices but it doesn't > work. > In log I have find this line: > ERROR: ClamInotif: could not watch path '/media'. 3 User clamav has > read permissions for this folder, nevertheless I can open eicar file > from my flash disk. However if I run clamdscan, clamav recognize this > file as malicious. ... Although I mostly use Linux and similar systems, I don't use ClamAV to scan them nor do I use on-access scanning in any way. I believe that there are a few issues with on-acccess scanning known and being worked on, but except that they are not necessarily obvious I don't kn
Re: [clamav-users] [External] Re: ClamAV 0.103.0 release candidate - systemd service start fails
NOTE: I can't speak to systemd intricacies but I can relay this information Centos 6.6 & 6.10 (current) which is a current, in maintenance period OS systemd script worked for 0.102.4 and before. script at http://talonator.pccc.com/clamav/ systemd script does NOT work for 0.103.0-rc on either 6.6 or 6.10. Micah, apologies, I changed too many things. However, killing the script leaves this running: defang 27767 20.3 3.2 1223676 1064732 ? Ssl 12:33 0:47 /usr/local/clamav/sbin/clamd Clamdscan can talk to it /usr/local/clamav/bin/clamdscan --version ClamAV 0.103.0-rc/25906/Fri Aug 21 09:10:42 2020 And I do appear to be able to scan. make check does NOT work on 6.6 Centos. make check does work on 6.10 Centos Hope this helps, KAM ___ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
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 > To: clamav-users@lists.clamav.net > Cc: Michael Orlitzky > 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 > > real0m25.409s > user0m0.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 ?Ssl0: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 ?Ssl0:00 clamd 32344 pts/2S+ 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
Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails
I have reproduced this error, and am currently working on a fix. See https://bugzilla.clamav.net/show_bug.cgi?id=12597. We made a change to create PID files before dropping privileges so that an unprivileged user cannot change the PID file and have the service manager kill the wrong process. Since there are still conditions that could cause the child process initialization to fail, the parent process waits for a signal that the child process is initialized to exit, so that it can report an accurate exit status. When the child drops privileges, it is not able to send SIGINT to the parent. I am currently working on a patch to have the parent drop privileges so that it can be signaled by the child. Thanks, Andy From: clamav-users on behalf of Michael Orlitzky via clamav-users Sent: Friday, August 21, 2020 12:20 PM To: clamav-users@lists.clamav.net Cc: Michael Orlitzky Subject: Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails On 2020-08-21 11:29, Arjen de Korte via clamav-users wrote: > >> # ps ax | grep clamd >> 7436 ?Ssl0:25 sbin/clamd > > # ps ax | grep clamd > 7840 pts/2S+ 0:00 /usr/sbin/clamd --debug > 7841 ?Ssl0:38 /usr/sbin/clamd --debug > > Previously I've waited for more than an hour, no change. The process > running under root never exits. > Ok, I can confirm this! After setting User clamav in clamd.conf, I've seen the root process get stuck as well. That's not an intended effect of the PID file change. ___ 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 ___ 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
