[clamav-users] Clamd Socket Occupied

[Reindl Harald]

Am 05.12.2017 um 19:52 schrieb Reindl Harald:
> Am 05.12.2017 um 19:34 schrieb Colony.three:
>>> Am 05.12.2017 um 08:13 schrieb Colony.three:
>>>
>>>> As Red Hat hasn't solved the problem of unix:sockets, I had to make 
>>>> my own systemd files. But there's a little problem.
>>>>
>>>> clamd.socket
>>>>
>>>> [Unit]
>>>> Description=Socket for Clam AntiVirus userspace daemon
>>>> Documentation=man:clamd(8) man:clamd.conf(5) 
>>>> http://www.clamav.net/lang/en/doc/
>>>> [Socket]
>>>> ListenStream=/run/clamav/clamd.sock
>>>>
>>>> this is a terrible idea because the daemon itself needs to support this
>>>> active - there is no reason for a systemd .socket file at all!
>>>>
>>>> just make a proper clamd unit and ensure proper permissions
>>
>> It would be dynamite if the daemon did in fact create the directory 
>> for its socket.  Unfortunately it does not.  Why do you think I went 
>> to all this trouble?
> 
> i don't konw because i have two clamd instances on Redhat systems, did 
> read the basic manpages as well as 
> https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
> 
> i can only tell you that clamd.socket won't solve any problem

"It would be dynamite if the daemon did in fact create the directory for 
its socket" - no, it would be normal if you configure it proper

https://www.freedesktop.org/software/systemd/man/systemd.exec.html
RuntimeDirectory is your friend
______________________

Tue Dec  5 07:10:55 2017 -> ERROR: LOCAL: Socket file 
/run/clamav/clamd.sock is in use by another process.

Huh?  It's in use by its own .socket.  The .socket runs fine, and when I 
stop it /run/clamav/clamd.sock goes away like it should.  Permissions 
are fine, and selinux is Permissive
______________________

and if you still did not understand it: you can't create a random socket 
with a .socket file until the daemon supports that

http://0pointer.de/blog/projects/socket-activation.html

A service capable of socket activation must be able to receive its 
preinitialized sockets from systemd, instead of creating them 
internally. For most services this requires (minimal) patching. However, 
since systemd actually provides inetd compatibility a service working 
with inetd will also work with systemd -- which is quite useful for 
services like sshd for example.