Bug#830482: [Pkg-clamav-devel] Bug#830482: Fresh installation causes freshclam to to fail

2017-05-05 Thread Sebastian Andrzej Siewior
On 2017-05-04 22:11:02 [+0200], To T. Joseph Carter wrote:
> I will try to reproduce this myself over the weekend. The original
> reported never came back to me. Just for the record: You run stable or
> testing? And all you did was just a plain install? And you do have
> systemd as default.

You replied that you were using `sid' but didn't Cc the bug so here I
add this detail for the protocol.

All you say is that once you have the "UpdateLogFile" entry then
freshclam won't work. Then you remove that line (or add # in front of
it) and it works. So this is something I can't reproduce. It worked
well here.
What is the error message that you face?

Sebastian



Bug#830482: [Pkg-clamav-devel] Bug#830482: Fresh installation causes freshclam to to fail

2017-05-04 Thread Sebastian Andrzej Siewior
On 2017-04-02 23:27:38 [-0700], T. Joseph Carter wrote:
> ​​I don't know if I will hit upon the issue in this bug or not, but I'll
> offer what I've just found in case it may be useful:
> 
> I found freshclam to fail freshly installed with the error message
> indicated in this bug.  Here is my freshclam.conf upon installation:

I will try to reproduce this myself over the weekend. The original
reported never came back to me. Just for the record: You run stable or
testing? And all you did was just a plain install? And you do have
systemd as default.

Sebastian



Bug#830482: Fresh installation causes freshclam to to fail

2017-04-03 Thread T. Joseph Carter
​​I don't know if I will hit upon the issue in this bug or not, but I'll
offer what I've just found in case it may be useful:

I found freshclam to fail freshly installed with the error message
indicated in this bug.  Here is my freshclam.conf upon installation:

```
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
ConnectTimeout 30
ReceiveTimeout 30
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
SafeBrowsing false
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
# Check for new database 24 times a day
Checks 24
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net
```

If you comment out the UpdateLogFile line, it'll run but be marked as a
modified conffile.  Didn't bother to check that this allows the (dead
"success") systemd service to do more than just die with no error when run
because no combination of debconf settings with ucf seemed to achieve the
effect of commenting out that line.

If I reconfigure it via debconf, it can be started.  Upon reconfiguring, I
have this config file:

```
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate false
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
ConnectTimeout 30
ReceiveTimeout 30
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
SafeBrowsing true
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
# Check for new database 24 times a day
Checks 24
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net
```
​
Upon doing this I can now start the daemon via systemctl and it stays
running.  My changes were minimal, and it appears the one that matters was
the log rotation setting.

I'm not sure in this configuration if systemd or freshclam is responsible
for logging.  If the latter, logs won't get rotated.  Before it'd rotate an
empty logfile and die.  Since it's no longer doing that, I assume systemd
is responsible and will rotate logs however it is configured to do so.
It's systemd, yay!

Hope that sheds some light on the problem.