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 [email protected] 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
