Comment 3 for bug 1590688

Hi,
here my initial analysis of the case.

## Check 0 - Debian bug status ##
No related Debian bug found

## Check 1 - Status on Xenial, Yakkety and Sid ##
Despite slight version differences all behave the same.

On all releases when starting freshclam some of the mirrors behind db.local.clamav.net failed, but after a while it found a working one.
That took up to 11 minutes in one case depending on mirror success and download speed - so nothing we can wait on on "install".
Also for the workaround mentioned that means, you might have to wait quite some time between starting freshclam and clamav-daemon

Since clamd was not yet running all reported a warning "Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.ctl: No such file or directory"

## Check #2 - Was this better in the past - is it a regression? ##
On Trusty (before systemd) instead of the "condition" prints
 Setting up clamav-daemon (0.98.7+dfsg-0ubuntu0.14.04.1) ...
  * Clamav signatures not found in /var/lib/clamav
  * Please retrieve them using freshclam
  * Then run '/etc/init.d/clamav-daemon start'
But freshclam is started automatically at least

On Jessie freshclam starts automatically
=> so that is a regression
But even after it finished it still runs into the "Can't connect to clamd through /var/run/clamav/clamd.ctl" as it blocked on start due to the condition check in the service.

## Perfect world scenario (=translates to fixes needed) ##
- Freshclam starts after install (all recent releases xenial, yakkety, sid broken in that regard)
- clamav-daemon picks up the condition is now valid and starts after freshclam updated the DB

## Fix 1 - get freshclam to autostart again ##
The clamav-freshclam.service file is byte identical in jessie (working) and sid (failing).
After discussing those with pitti he suggested that the postinst might be incomplete.
Some things are not done via dh_installinit or dh_systemd_start but instead manually.
Then eventually it calls invoke-rc.d before enabling the unit.
This should likely move after ##DEBHELPER##.

To make it clear - there was no postinst change between jessie (working) and sid (fails), but invoke-rc-d might have used to start disabled things.

## Fix 2 - could clamav-daemon start once synced? ##
Re-pickup condition in systemd not built in to Condition statements.
ExecStartPre= and waiting for update not an option as it is not allowed to take long.
Discussed with systemd IRC channel - and they suggested a systemd.path unit.

I'm not deep enough into systemd yet to predict if that conflicts with the .socket file which is created by the postinst.
After reading docs that would look like (in addition to /lib/systemd/system/clamav-daemon.service):
cat /lib/systemd/system/clamav-daemon.path
[Path]
PathExistsGlob=/var/lib/clamav/main.{c[vl]d,inc}
PathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc}

Also we could at least change the Condition to an Assert to avoid having it fail silently AND due to the path based activation should never happen again.

I'll create and test a fix for sid, suggest it to the debian maintainer.
If successful we can pick it up on next merge and/or backport it as needed.