clamav's ebuild installs one initscript that is used to start clamd, freshclam, and clamav-milter. This is similar to samba's initscripts setup. However, many other packages, such as mit-krb5 and openrc, have multiple initscripts. When multiple daemons are started by one initscript, problems (such as that mentioned in this bug's URL) can occcur. If the last deamon doesn't start, the initscript script has to either remember to stop the already-started daemons before exiting with a ``failed'' status. Otherwise, half of the daemons are still running and require the use of killall rather than ``rc-service clamd stop'' to stop them. There should be three scripts for clamd. 1. clamd: requires the script freshclam to be up depending on a variable in /etc/conf.d/clamd (because some people could run freshclam from crond) 2. freshclam: should be independent, because one may want up-to-date clam virus signatures for use with clamscan and avoid running a system clamd server 3. clamav-milter: should require the clamd initscript This will allow robustness of scripts and more logical management of the daemons by users.
Created attachment 198658 [details] independent clamd initscript I'm sorry that this isn't a patch, but the differences against the original clamd are too big for one to edit the original based on a small patch. I think that the code which checks for clamd's socket to be created is superfluous. There is the possibility that the user may create a TCPSocket only. Also, upon observation of the behavior of app-antivirus/clamav-0.95.2's clamd, the clamd process does not background until after the database is loaded (and the sockets opened). Also, clamav-milter is becoming better at connecting and reconnecting to clamd sockets. I don't think that the socket even has to exist for clamav-milter to start (although the milter would be useless until clamd has started).
Created attachment 198660 [details] independent clamav-milter initscript
Created attachment 198662 [details] independent freshclam initscript I have a sample clamav-0.95.2 ebuild setup using these modularized initscripts. Use the following command to sample it: layman -o http://ohnopublishing.net/~ohnobinki/gentoo/binkioverlay.xml -f -a ohnobinki_overlay_hg (don't forget to layman -d ohnobinki_overlay_hg later)
Another problem is, that openrc does not recognize a crash of one of the components and reports the service running although it is not. With seperate init scripts this can be avoided.
I'll have a look at this when I get a chance, but consider it low priority for now
For lack of a better place to put it: once the tmpfiles.d entry has been fixed in bug 582110, the init script for all three clamav services can be greatly simplified. I'd suggest: * Delete the get_config function. The init script shouldn't be trying to parse a config file to obtain random strings and then call "chown" on them... this is surprising, and a security risk -- but doesn't need to happen anyway. The only path that the init script should *ever* have to worry about is under /run, because it isn't persistent. If the user wants to e.g. move his logs, then he can move them and put the right permissions on the new directory and be done with it. The init script shouldn't try to guess at that each time the service starts, and start messing with the permissions that the administrator already set. This brings the OpenRC behavior closer to that of systemd as well, since systemd thankfully doesn't have any way to try to parse the config file as part of the "daemon start" process. So the systemd service sets up /run/clamav, and then trusts that you either haven't messed with the defaults that were set up correctly; or, if you have, that you've set the right permissions on the non-default things. So eliminating the config parsing from the OpenRC init script makes the two work the same. * Delete the logfix function. If logrotate breaks the logging, then it's because there's something else screwed up. The default log location should be root:clamav and mode 770, and there's no reason to ever "fix" anything in that directory. * Get rid of all the checkpath calls in start(). The group, mode, etc. of the socket is configurable and in any case is not the responsibility of the init system. Now you're left with three trivial init scripts =)
As promised, see the new $URL for an upstream pull request that provides four separate OpenRC service scripts. Feedback is welcome, especially for clamonacc and clamav-milter, which I do not personally use.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8038d96958974432777d667fae883516eebad258 commit 8038d96958974432777d667fae883516eebad258 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-09-20 17:08:41 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-09-20 19:28:56 +0000 app-antivirus/clamav: new version 0.103.0. New version with lots of good stuff. The main changes are that on-access scanning is now controlled by USE=clamonacc, and that we provide separate OpenRC services for the various daemons. Closes: https://bugs.gentoo.org/272963 Closes: https://bugs.gentoo.org/670729 Closes: https://bugs.gentoo.org/732926 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> app-antivirus/clamav/Manifest | 1 + app-antivirus/clamav/clamav-0.103.0.ebuild | 219 ++++++++++ .../files/clamav-0.103.0-system-tomsfastmath.patch | 115 ++++++ .../files/clamav-0.103.0-upstream-openrc.patch | 447 +++++++++++++++++++++ app-antivirus/clamav/metadata.xml | 1 + 5 files changed, 783 insertions(+)
