The changes in the init script introduced in this version are problematic for setups where clamav socket is used by amavisd-new in chroot mode. amavis is restricted to its chroot (/var/amavis) so one is forced to put the clamd socket into this directory for access for amavis. The new init script not only checks correct ownership of the configured clamav directories, it also changes ownership of these. After starting clamav via init script the amavis working directory has changed ownership clamav user and amavis no longer has access to his working directory and fails.
Run amavis and clamav as the same user instead of relying on AllowSupplementaryGroups if running in chroot. We need the directory check in clamav init script because clamav run dir might reside on tmpfs.
Back to stone age... I can´t believe this is the only possible solution and the only way, this is SIMPLY a matter of some additional logic! At least this is a very bad user experience when someone installs a package that breaks a working config without a big fat warning on install that something has fundamentally changed. Second, I assume running clamav or amavis on tmpfs at bigger hp setups that benefit from this is far less frequent than the huge number of small boxes perfectly running on low load without those tuning measures. So you sacrifice a high user number setups for far less hp boxes... I do not get the point why this should make sense. A better way supporting both would be a smarter init script. We will see what happens when this goes stable.
(In reply to comment #2) > Second, I assume running clamav or amavis on tmpfs at bigger hp setups that > benefit from this is far less frequent No, /run or /var/run on tmpfs is probably going to be the default once all the bugs are ironed out - see bug #332633. It is pretty common already. > I do not get the point why this should make sense. A better way supporting > both would be a smarter init script. And do what exactly? See if amavisd-new is installed, parse its config file - which you can't do reliably without forking a perl interpreter by the way-, assume clamav and amavisd-new are working together, second guess the sysadmin and adjust ownership? And this is a better solution how? > We will see what happens when this goes stable. It is already stable on clamav-0.97.5-r1. If you are running amavisd-new in chroot, adjust your config files accordingly. Running clamav and amavisd-new under the same user is not uncommon.
