Bug 723544 - clamav-server (clamd) fails on reboot because /var/run is now tmpfs.
Summary: clamav-server (clamd) fails on reboot because /var/run is now tmpfs.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: clamav
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Enrico Scholz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 702815 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-20 14:32 UTC by Arthur Dent
Modified: 2012-08-07 16:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 16:11:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Arthur Dent 2011-07-20 14:32:50 UTC
Description of problem:

On reboot, clamd always fails. This is because it is configured to write a PID to the PidFile /var/run/clamd.clamd/clamd.pid

/var/run/ is now tempfs and is therefore wiped clean at reboot. There is no command to mkdir and chown the directory for this PIDfile in the init script (/etc/init.d/clamd-wrapper -> /usr/share/clamav/clamd-wrapper).

In any case this should probably be looked at and changed to a native systemd unit.

In the meantime I have (sort of) solved this by putting the following in the "start" stanza of the init script:
======8<==================
if [ !-d $piddir ] ; then
         mkdir $piddir}
     fi
======8<==================

Version-Release number of selected component (if applicable):
clamav-server-sysvinit-0.97.1-1500.fc15.noarch
clamav-server-0.97.1-1500.fc15.i686
clamav-filesystem-0.97.1-1500.fc15.noarch
clamav-data-empty-0.97.1-1500.fc15.noarch
clamav-lib-0.97.1-1500.fc15.i686
clamav-0.97.1-1500.fc15.i686
clamav-update-0.97.1-1500.fc15.i686


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Arthur Dent 2011-07-20 14:55:43 UTC
Correction:

Typo. - The modification to the clamd-wrapper script should read:


In the definitions section:
CLAMD_PIDDIR=/var/run/clamd.${CLAMD_SERVICE}

and in the "start" stanza:
======8<==================
	if [ ! -d $CLAMD_PIDDIR ] ; then
         mkdir $CLAMD_PIDDIR && chown clamd:clamd $CLAMD_PIDDIR
     	fi
======8<==================

Comment 2 Nathanael Noblet 2011-07-20 18:39:05 UTC
The proper solution is a tmpfile config.

/etc/tmpfiles.d/clamav.conf

with contents like

d /var/run/DIR 0770 USER GROUP -

for what needs to be created.

Comment 3 Arthur Dent 2011-07-20 18:51:34 UTC
Ahh! Interesting.

Thanks.

I'm going to try it now (well later tonight...)

What about the issue of creating a native systemd unit? It will need to be done before F16, and others must have the same problem on F15 - could it be done now?

Comment 4 Arthur Dent 2011-07-21 18:02:30 UTC
OK I can confirm that this works.

I believe that it should remain logged as a bug, because if this is the way it is supposed to work then the Fedora package should include a 
/etc/tmpfiles.d/clamd.conf file - which it does not.
(Or it should include a working systemd configuration).

While we're on the subject, I think that there is more work that should be done on this package. Every time I do a fresh install of Fedora, I have a terrible battle to get clamd working. The Fedora package should, surely, Just Work (tm).

As a minimum I would expect that a Fedora package would:

1) Create a new and appropriate user (apparently "clamav" as created for the general clamav package should not be used, so something like "clamd" should be used for clamav-server).

2) Fix ALL the SELinux problems. I have a custom module that takes me days to get right with each new install.

3) Have working init / systemd scripts.

4) Ideally have working configuration files. I know that even the upstream package requires configuration (removing/commenting the "example" line in the config file, selecting the appropriate DatabaseMirror, etc) but my view is that if I'm installing it I want it to work...

We could argue about 4, but 1,2 & 3 I really believe should be fixed...

Comment 5 Nick Bebout 2011-08-14 00:33:30 UTC
*** Bug 702815 has been marked as a duplicate of this bug. ***

Comment 6 Fedora End Of Life 2012-08-07 16:11:19 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.