Hi there,
On Mon, 9 May 2022, Anthony Griffiths via clamav-users wrote:
> clamav will not create a clamd.sock file when started up.
> I've tried so many different things but I don't know what else to do
> to get clamav to create this socket file.
There are quite a few things which can go wrong. Trying to do things
without a clear plan of attack is most unlikely to get you where you
want to be. You need an ordered, logical approach based on the way
things are in Unix-style systems. Welcome to system administration!
> in clamd.conf I have
> LocalSocket /var/spool/MIMEDefang/clamd.sock
> LocalSocketGroup defang
> FixStaleSocket yes
> User defang
>
> but in the maillog I keep getting mimedefang.<snip>: Could not connect
> to clamd daemon at /var/spool/MIMEDefang/clamd.sock
> thats because the file isn't there because clamav just will not create
> it. I've tried rebooting the machine but it still doesn't work. I know
> I'll never resolve this problem unless I can get clamav to create a
> clamd.sock file but I'm stumped as to why it will not create one
For clamd to create a socket in the directory /var/spool/MIMEDefang/
several things are necessary. Normally most of it would be taken care
of automatically when you install packages from your distribution, and
if you did use packages I wonder where things went wrong, but we can
worry about that later. Off the top of my head:
1. The clamd configuration must specify that that is where it's to be.
2. The user and group in the configuration must exist on the system.
3. The configured directory must exist.
4. The configured directory must be writeable by the clamd process.
5. There must not be an existing file/socket with the same name in the
same directory, especially one with different owner/group/permissions
which gets in the way. I think we've got this covered. :)
6. The clamd process must have been started.
7. The clamd process must at least have attempted to create the socket,
in other words nothing _else_ must have gone wrong before it tried. :/
You haven't given enough information for me to know that most of those
things is true, so we'll need to do a bit of work. It isn't difficult
but it won't happen by accident. Taking the requirements one by one:
1. You've said that clamd.conf contains some things, but you haven't
shown any evidence that when you try to start clamd it's really using
that file for its configuration. Can you demonstrate that somehow?
Many distributions invite confusion because they change the upstream
defaults for configuration file locations and names, then set up their
own scripts to start, stop and query daemons like clamd. It might not
be obvious what's really being used. One way to be sure is to run the
clamd daemon directly from the command line, for example something like
# /usr/local/sbin/clamd -c /usr/local/etc/clamd.conf
but note that I've just given this as an example. Your clamd binary
might not be in /usr/local/sbin/ (although it *is* very likely called
'clamd') and your clamd.conf might not be in /usr/local/etc/ (and it
might not be called clamd.conf, and there might even be more than one
file making up the configuration - and then more work may be needed).
Note that this is a command issued by root, that's necessary so that
the clamd process can change its UID and GID to those configured; if
you run the command as an unprivileged user, it won't work unless the
user is the one configured in the clamd.conf file. Quite often when
you run a daemon from the command line you'll get error messages sent
to the terminal instead of some log file somewhere if some boot script
starts it for you. That often helps track down problems.
2. Can you show that the user and group specified in the configuration
file exist on the system? Look in /etc/passwd and /etc/group for them,
for example
# grep defang /etc/passwd /etc/group
3. Have you satisfied yourself that the configured directory exists?
You can do this with the command 'ls /var/spool/' for example.
4. Have you satisfied yourself that clamd could write to that directory
when it runs with the permissions that your configuration will give to
it? Again, the 'ls' command (with the -l option) will be useful as it
tells you the owner, group and permissions. You'll need something like
# ls -l /var/spool/
...
...
drwxr-x--- 2 defang defang 60 May 7 12:17 MIMEDefang
....
....
This snippet of output says amongst other things that MIMEDefang is a
directory, that the user 'defang' can read, write and search it, that
the group 'defang' can read and search BUT NOT WRITE in it, and that
other users can't do anything in there at all. You *might* want the
'group write' bit set (drwxrwx--- instead of drwxr-x---) but only if
you want some process which is *not* owned by the defang user but *is*
in that group to be able to write in there. You probably don't, as
it's clamd which will create the socket in there (and so needs write
permission) but nothing else needs it. You don't need to be able to
write to the directory to be able to write to a file within it - that
just needs write permission on the file itself, something like this:
# ls -l /var/spool/MIMEDefang/
...
srw-rw---- 1 defang defang 4 May 7 12:17 clamd.sock
...
Note that when you give the command
# ls -l /var/spool/MIMEDefang/
you see the *content* of the directory, not the directory itself.
The 'chmod' and 'chown' commands set permissions. You might want to
create a script or modify an existing one if it's going to be run more
often than you feel like typing the commands. Sometimes directories
in which sockets are placed are created at boot time, and you might
need to set the permissions somewhere in a configuration or script so
they get set to what you want at boot.
5. We think there's nothing getting in the way of creating the socket.
Ideally to begin with /var/spool/MIMEDefang/ will be empty, but there
shouldn't be any old socket with the same name lying around. If there
is, you can remove it with the 'rm' command. You've said that there
isn't, so we can probably skip this one.
6. Have you any evidence that clamd has tried to start? For example
you might start clamd in one terminal while running 'top' in another
to see the process starting. You could tell 'top' to show only those
processes with user ID 'defang' so the display is more digestible or
you can sort the output by memory usage in which case clamd will most
likely go to the top of the list pretty soon after it starts. You
can also use the 'ps' and 'grep' commands to list processes with the
text 'clamd' in the output of 'ps', this is on my clamd server:
# ps -ef | grep clamd
clamav 712 1 0 May07 ? 00:10:51 /usr/local/sbin/clamd --config-file=/etc/mail/clamav/clamd_tcp3.conf
root 1786 10631 0 18:05 pts/2 00:00:00 grep clamd
7. Have you any evidence that clamd has tried to create the socket?
You might find something about that in the system logs in /var/log/ or
in a log file that you've configured in clamd.conf or whatever. As I
mentioned in my earlier reply you can configure the logging verbosity,
when things are being difficult that's usually well worth doing. If
clamd tries to create the socket but fails (e.g. permissions) then it
should tell you in the log. Of course it needs to be able to write to
the log as well, and if in your configuration you tell it to use the
'syslog' system rather than specifying some random log file you have a
better chance that the logs will get written. Finding them might not
be quite so easy, but the files named syslog, messages and daemon.log
in the /var/log/ directory are good candidates. I prefer to make a
directory in /var/log/ called 'clamav', then set the owner and group
of /var/log/clamav/ to be those of the running clamd process (in your
case 'defang.defang') so I know that it can write to the log.
Lastly, I've only covered the issue of creating the socket. It might
take a little time for clamd to start (because it has to read millions
of signatures) and even when the socket has been created you need to
make sure that MIMEDefang can use it - check, and if necessary adjust,
the permissions or the UID and/or GID of the MIMEDefang process.
All this takes a lot longer to write down than it actually does to do
when you're more familiar with this stuff. It will eventually become
second nature, and you'll wonder what all the trouble was. :)
When you get back to us again, please try to show the output of things
like the commands I've suggested above and tell us exactly what you've
done to install, configure and run clamav and MIMEDefang. It's a lot
easier to find problems if we have more information to work with.
I think I've covered most of the things that might be messed up but I
could easily have forgotten something. Do shout if you think so.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml