Mailing List Archive

ClamAV 0.103.0 release candidate - systemd service start fails
OS: openSUSE Tumbleweed

I have found (like others) that the ClamAV 0.103.0-rc service doesn't
start. When running the binary in a console, it doesn't daemonize, but
keeps running. PID file and socket are created however.

I bisected this problem and found the commit

bb12435: Create PID file before dropping privileges.

to be the culprit here. Reverting that one, all is well.

It is not clear to me what problem this patch intends to solve (for a
systemd service it is absolute not required from a security point of
view). The PIDFile should be writable by vscan user only anyway.


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
Citeren Arjen de Korte via clamav-users <clamav-users@lists.clamav.net>:

> OS: openSUSE Tumbleweed
>
> I have found (like others) that the ClamAV 0.103.0-rc service
> doesn't start. When running the binary in a console, it doesn't
> daemonize, but keeps running. PID file and socket are created however.

That should have read the clamd.service and the /usr/sbin/clamd binary
respectively.

> I bisected this problem and found the commit
>
> bb12435: Create PID file before dropping privileges.
>
> to be the culprit here. Reverting that one, all is well.
>
> It is not clear to me what problem this patch intends to solve (for
> a systemd service it is absolute not required from a security point
> of view). The PIDFile should be writable by vscan user only anyway.




_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote:
>
> It is not clear to me what problem this patch intends to solve (for a
> systemd service it is absolute not required from a security point of
> view). The PIDFile should be writable by vscan user only anyway.
>

With a Type=forking service, systemd will send SIGTERM to the contents
of the PID file as root. If the "vscan" user can put whatever he wants
in the PID file, then he can kill root processes.

Are you using the upstream systemd service? It defaults to Type=simple,
and runs clamd in the foreground. In that case, your clamd daemon
shouldn't be creating a PID file at all -- systemd should take care of
it when it shoves the process into the background. PidFile should be
left unset in clamd.conf.


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:

> On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote:
>>
>> It is not clear to me what problem this patch intends to solve (for a
>> systemd service it is absolute not required from a security point of
>> view). The PIDFile should be writable by vscan user only anyway.
>>
>
> With a Type=forking service, systemd will send SIGTERM to the contents
> of the PID file as root.

Not unconditionally. See the following from 'man 5 systemd.service':

"The PID file does not need to be owned by a privileged user, but if it
is owned by an unprivileged user additional safety restrictions are
enforced: the file may not be a symlink to a file owned by a different
user (neither directly nor indirectly), and the PID file must refer to
a process already belonging to the service."

> If the "vscan" user can put whatever he wants
> in the PID file, then he can kill root processes.

See above: you're trying to fix a problem that doesn't exist.

> Are you using the upstream systemd service?

No, we're using "Type=forking" since the clamd.service can take
several minutes to start and we don't want to start services that
depend on it before it actually finished starting up. Creating the
socket beforehand is not a solution, as clamd won't start serving any
requests until it has actually finished starting up.

> It defaults to Type=simple, and runs clamd in the foreground.

See above. Actually, with this patch clamd wil always run in the
foreground, as daemonizing is now completely broken. Up to and
including 0.102.4, starting clamd on the commandline without any
further options would just start the daemon and return. Now, it never
returns.

> In that case, your clamd daemon
> shouldn't be creating a PID file at all -- systemd should take care of
> it when it shoves the process into the background. PidFile should be
> left unset in clamd.conf.

There is no PIDFile in the clamd.service file as systemd doesn't need
that here (even when running as Type=forking). The same goes for
freshclam.service. Systemd has other ways to keep track of which
processes it has started and will not use the PIDFile unless you tell
it to do so (with the above mentioned restrictions).


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote:
> Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:
>
>> On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote:
>>>
>>> It is not clear to me what problem this patch intends to solve (for a
>>> systemd service it is absolute not required from a security point of
>>> view). The PIDFile should be writable by vscan user only anyway.
>>>
>>
>> With a Type=forking service, systemd will send SIGTERM to the contents
>> of the PID file as root.
>
> Not unconditionally. See the following from 'man 5 systemd.service':
>
> "The PID file does not need to be owned by a privileged user, but if it
> is owned by an unprivileged user additional safety restrictions are
> enforced: the file may not be a symlink to a file owned by a different
> user (neither directly nor indirectly), and the PID file must refer to
> a process already belonging to the service."
>

That's good to hear (and is news to me), and maybe they've found another
way to prevent this vulnerability in systemd.


>> If the "vscan" user can put whatever he wants
>> in the PID file, then he can kill root processes.
>
> See above: you're trying to fix a problem that doesn't exist.

However, systemd isn't the only service manager, and the problem still
exists in all of the other ones. Systemd is able to avail itself of
platform-specific features in brand-new Linux kernels. SysV init,
OpenRC, and others must stick to real or de-facto standard tools, and
there is no standard way to implement what systemd says they've done.


>> Are you using the upstream systemd service?
>
> No, we're using "Type=forking" since the clamd.service can take
> several minutes to start and we don't want to start services that
> depend on it before it actually finished starting up. Creating the
> socket beforehand is not a solution, as clamd won't start serving any
> requests until it has actually finished starting up.

That's fine, now you just need to synchronize the PIDFile and PidFile
entries in your systemd service and clamd.conf, respectively. I suggest
/run/clamd.pid, or any other location that is writable only by root.


>> It defaults to Type=simple, and runs clamd in the foreground.
>
> See above. Actually, with this patch clamd wil always run in the
> foreground, as daemonizing is now completely broken. Up to and
> including 0.102.4, starting clamd on the commandline without any
> further options would just start the daemon and return. Now, it never
> returns.
That's not true, your service file just needs to know where the PID file
lives. It always did, but somehow it managed to not crash in the past.


>> In that case, your clamd daemon
>> shouldn't be creating a PID file at all -- systemd should take care of
>> it when it shoves the process into the background. PidFile should be
>> left unset in clamd.conf.
>
> There is no PIDFile in the clamd.service file as systemd doesn't need
> that here (even when running as Type=forking). The same goes for
> freshclam.service. Systemd has other ways to keep track of which
> processes it has started and will not use the PIDFile unless you tell
> it to do so (with the above mentioned restrictions).

Well empirically that's not true, because it isn't working. Add PIDFile
entries to your service files when using Type=forking, and synchronize
them with the PidFile lines in clamd.conf and freshclam.conf.

_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote:
>
> Not unconditionally. See the following from 'man 5 systemd.service':
>
> "The PID file does not need to be owned by a privileged user, but if it
> is owned by an unprivileged user additional safety restrictions are
> enforced: the file may not be a symlink to a file owned by a different
> user (neither directly nor indirectly), and the PID file must refer to
> a process already belonging to the service."
>

FWIW this was committed on Jan 8th 2018, and solves the problem by
keeping a separate pid <-> process <-> service map that's writable only
by root. The patch in question provides the same security to other
service managers.

_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:

> On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote:
>> Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:
>>
>>> On 2020-08-21 04:45, Arjen de Korte via clamav-users wrote:
>>>>
>>>> It is not clear to me what problem this patch intends to solve (for a
>>>> systemd service it is absolute not required from a security point of
>>>> view). The PIDFile should be writable by vscan user only anyway.
>>>>
>>>
>>> With a Type=forking service, systemd will send SIGTERM to the contents
>>> of the PID file as root.
>>
>> Not unconditionally. See the following from 'man 5 systemd.service':
>>
>> "The PID file does not need to be owned by a privileged user, but if it
>> is owned by an unprivileged user additional safety restrictions are
>> enforced: the file may not be a symlink to a file owned by a different
>> user (neither directly nor indirectly), and the PID file must refer to
>> a process already belonging to the service."
>>
>
> That's good to hear (and is news to me), and maybe they've found another
> way to prevent this vulnerability in systemd.
>
>
>>> If the "vscan" user can put whatever he wants
>>> in the PID file, then he can kill root processes.
>>
>> See above: you're trying to fix a problem that doesn't exist.
>
> However, systemd isn't the only service manager, and the problem still
> exists in all of the other ones. Systemd is able to avail itself of
> platform-specific features in brand-new Linux kernels. SysV init,
> OpenRC, and others must stick to real or de-facto standard tools, and
> there is no standard way to implement what systemd says they've done.

That may be, but now you have replaced it with two processes that run
in the foreground, one of them as unpriviledged user and one as root
(probably to delete the PIDFile upon exit). I don't consider this
progress.

>>> Are you using the upstream systemd service?
>>
>> No, we're using "Type=forking" since the clamd.service can take
>> several minutes to start and we don't want to start services that
>> depend on it before it actually finished starting up. Creating the
>> socket beforehand is not a solution, as clamd won't start serving any
>> requests until it has actually finished starting up.
>
> That's fine, now you just need to synchronize the PIDFile and PidFile
> entries in your systemd service and clamd.conf, respectively.

No, as stated before, systemd doesn't need the PIDFile at all. It
keeps track of the processes it started without the help of a PIDFile.
It *can* use a PIDFile if you provide it with one and the only thing
it will do with that is to remove that file if the service doesn't do
it itself upon exit. Nothing more, it is not used for process control.
There is absolutely no need for a PIDFile in the clamd.service, even
with Type=forking.

> I suggest
> /run/clamd.pid, or any other location that is writable only by root.

It's fine where it is now. See above: systemd doesn't care.

>>> It defaults to Type=simple, and runs clamd in the foreground.
>>
>> See above. Actually, with this patch clamd wil always run in the
>> foreground, as daemonizing is now completely broken. Up to and
>> including 0.102.4, starting clamd on the commandline without any
>> further options would just start the daemon and return. Now, it never
>> returns.
> That's not true, your service file just needs to know where the PID file
> lives. It always did, but somehow it managed to not crash in the past.

No, it doesn't, see above. Even if I start clamd on the commandline
(which should then daemonize, unless told by --foreground to stay in
the foreground) without any of this. This is a regression and has
nothing to do with systemd.

>>> In that case, your clamd daemon
>>> shouldn't be creating a PID file at all -- systemd should take care of
>>> it when it shoves the process into the background. PidFile should be
>>> left unset in clamd.conf.
>>
>> There is no PIDFile in the clamd.service file as systemd doesn't need
>> that here (even when running as Type=forking). The same goes for
>> freshclam.service. Systemd has other ways to keep track of which
>> processes it has started and will not use the PIDFile unless you tell
>> it to do so (with the above mentioned restrictions).
>
> Well empirically that's not true, because it isn't working. Add PIDFile
> entries to your service files when using Type=forking, and synchronize
> them with the PidFile lines in clamd.conf and freshclam.conf.

Makes no difference at all. Even without using systemd, clamd doesn't
daemonize anymore, it will always run in the foreground.


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:

> On 2020-08-21 08:11, Arjen de Korte via clamav-users wrote:
>>
>> Not unconditionally. See the following from 'man 5 systemd.service':
>>
>> "The PID file does not need to be owned by a privileged user, but if it
>> is owned by an unprivileged user additional safety restrictions are
>> enforced: the file may not be a symlink to a file owned by a different
>> user (neither directly nor indirectly), and the PID file must refer to
>> a process already belonging to the service."
>>
>
> FWIW this was committed on Jan 8th 2018, and solves the problem by
> keeping a separate pid <-> process <-> service map that's writable only
> by root. The patch in question provides the same security to other
> service managers.

Great, but what happened to daemonizing clamd?


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On 2020-08-21 09:38, Arjen de Korte via clamav-users wrote:
>>
>> However, systemd isn't the only service manager, and the problem still
>> exists in all of the other ones. Systemd is able to avail itself of
>> platform-specific features in brand-new Linux kernels. SysV init,
>> OpenRC, and others must stick to real or de-facto standard tools, and
>> there is no standard way to implement what systemd says they've done.
>
> That may be, but now you have replaced it with two processes that run
> in the foreground, one of them as unpriviledged user and one as root
> (probably to delete the PIDFile upon exit). I don't consider this
> progress.
>

The clamd process starts in the foreground, and then forks (a new
process) to the background. The PID file should contain the PID of the
forked process. No root process should be left running in the
foreground; the service manager is in charge of cleaning up the file.


>>
>> That's fine, now you just need to synchronize the PIDFile and PidFile
>> entries in your systemd service and clamd.conf, respectively.
>
> No, as stated before, systemd doesn't need the PIDFile at all. It
> keeps track of the processes it started without the help of a PIDFile.
> It *can* use a PIDFile if you provide it with one and the only thing
> it will do with that is to remove that file if the service doesn't do
> it itself upon exit. Nothing more, it is not used for process control.
> There is absolutely no need for a PIDFile in the clamd.service, even
> with Type=forking.

Systemd tries to guess the PID file with Type=forking when you don't
provide one (the GuessMainPID option). Either way, systemd does need to
know the PID file's location -- the only question is whether or not it's
able to guess. Something isn't working, so to rule some things out, it
might help to point it at the PID file manually.


>> Well empirically that's not true, because it isn't working. Add PIDFile
>> entries to your service files when using Type=forking, and synchronize
>> them with the PidFile lines in clamd.conf and freshclam.conf.
>
> Makes no difference at all. Even without using systemd, clamd doesn't
> daemonize anymore, it will always run in the foreground.

How long have you waited for clamd to start? With git head (and only
official signatures), it takes about 25 seconds here:

# time sbin/clamd

real 0m25.409s
user 0m0.005s
sys 0m0.005s

but after that the process does indeed fork into the background. If it
doesn't, maybe we're looking in the wrong place. The PID file also
points to the correct (forked) process in my case:

# cat run/clamd.pid
7436
# ps ax | grep clamd
7436 ? Ssl 0:25 sbin/clamd

_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
Citeren Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>:

>>> Well empirically that's not true, because it isn't working. Add PIDFile
>>> entries to your service files when using Type=forking, and synchronize
>>> them with the PidFile lines in clamd.conf and freshclam.conf.
>>
>> Makes no difference at all. Even without using systemd, clamd doesn't
>> daemonize anymore, it will always run in the foreground.
>
> How long have you waited for clamd to start? With git head (and only
> official signatures), it takes about 25 seconds here:
>
> # time sbin/clamd
>
> real 0m25.409s
> user 0m0.005s
> sys 0m0.005s

Loading takes a similar amount of time here, from the time starting
'/usr/sbin/clamd --debug' to the moment the line

aug 21 17:14:12 orthros clamd[7841]: Self checking every 600 seconds.

is logged.

> but after that the process does indeed fork into the background. If it
> doesn't, maybe we're looking in the wrong place. The PID file also
> points to the correct (forked) process in my case:
>
> # cat run/clamd.pid
> 7436

In a different command window:

# cat /run/clamav/clamd.pid
7841

So the PID file seems to contain the correct information

> # ps ax | grep clamd
> 7436 ? Ssl 0:25 sbin/clamd

# ps ax | grep clamd
7840 pts/2 S+ 0:00 /usr/sbin/clamd --debug
7841 ? Ssl 0:38 /usr/sbin/clamd --debug

Previously I've waited for more than an hour, no change. The process
running under root never exits.


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On 2020-08-21 11:29, Arjen de Korte via clamav-users wrote:
>
>> # ps ax | grep clamd
>> 7436 ? Ssl 0:25 sbin/clamd
>
> # ps ax | grep clamd
> 7840 pts/2 S+ 0:00 /usr/sbin/clamd --debug
> 7841 ? Ssl 0:38 /usr/sbin/clamd --debug
>
> Previously I've waited for more than an hour, no change. The process
> running under root never exits.
>

Ok, I can confirm this! After setting

User clamav

in clamd.conf, I've seen the root process get stuck as well. That's not
an intended effect of the PID file change.


_______________________________________________

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
Re: [External] Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
NOTE: I can't speak to systemd intricacies but I can relay this information

Centos 6.6 & 6.10 (current) which is a current, in maintenance period OS

systemd script worked for 0.102.4 and before. script at
http://talonator.pccc.com/clamav/

systemd script does NOT work for 0.103.0-rc on either 6.6 or 6.10. 
Micah, apologies, I changed too many things.

However, killing the script leaves this running:

defang   27767 20.3  3.2 1223676 1064732 ?     Ssl  12:33   0:47
/usr/local/clamav/sbin/clamd

Clamdscan can talk to it

 /usr/local/clamav/bin/clamdscan --version
ClamAV 0.103.0-rc/25906/Fri Aug 21 09:10:42 2020

And I do appear to be able to scan.

make check does NOT work on 6.6 Centos.

make check does work on 6.10 Centos

Hope this helps,

KAM


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
On Fri, 21 Aug 2020, Michael Orlitzky via clamav-users wrote:

> Date: Fri, 21 Aug 2020 10:18:42 -0400
> From: Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>
> To: clamav-users@lists.clamav.net
> Cc: Michael Orlitzky <michael@orlitzky.com>
> Subject: Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd
> service start fails
>
> On 2020-08-21 09:38, Arjen de Korte via clamav-users wrote:
> >>
> >> However, systemd isn't the only service manager, and the problem still
> >> exists in all of the other ones. Systemd is able to avail itself of
> >> platform-specific features in brand-new Linux kernels. SysV init,
> >> OpenRC, and others must stick to real or de-facto standard tools, and
> >> there is no standard way to implement what systemd says they've done.
> >
> > That may be, but now you have replaced it with two processes that run
> > in the foreground, one of them as unpriviledged user and one as root
> > (probably to delete the PIDFile upon exit). I don't consider this
> > progress.
> >
>
> The clamd process starts in the foreground, and then forks (a new
> process) to the background. The PID file should contain the PID of the
> forked process. No root process should be left running in the
> foreground; the service manager is in charge of cleaning up the file.
>
>
> >>
> >> That's fine, now you just need to synchronize the PIDFile and PidFile
> >> entries in your systemd service and clamd.conf, respectively.
> >
> > No, as stated before, systemd doesn't need the PIDFile at all. It
> > keeps track of the processes it started without the help of a PIDFile.
> > It *can* use a PIDFile if you provide it with one and the only thing
> > it will do with that is to remove that file if the service doesn't do
> > it itself upon exit. Nothing more, it is not used for process control.
> > There is absolutely no need for a PIDFile in the clamd.service, even
> > with Type=forking.
>
> Systemd tries to guess the PID file with Type=forking when you don't
> provide one (the GuessMainPID option). Either way, systemd does need to
> know the PID file's location -- the only question is whether or not it's
> able to guess. Something isn't working, so to rule some things out, it
> might help to point it at the PID file manually.
>
>
> >> Well empirically that's not true, because it isn't working. Add PIDFile
> >> entries to your service files when using Type=forking, and synchronize
> >> them with the PidFile lines in clamd.conf and freshclam.conf.
> >
> > Makes no difference at all. Even without using systemd, clamd doesn't
> > daemonize anymore, it will always run in the foreground.
>
> How long have you waited for clamd to start? With git head (and only
> official signatures), it takes about 25 seconds here:
>
> # time sbin/clamd
>
> real 0m25.409s
> user 0m0.005s
> sys 0m0.005s
>
> but after that the process does indeed fork into the background. If it
> doesn't, maybe we're looking in the wrong place. The PID file also
> points to the correct (forked) process in my case:
>
> # cat run/clamd.pid
> 7436
> # ps ax | grep clamd
> 7436 ? Ssl 0:25 sbin/clamd
>
[hubble:root]:(~)# service clamd stop
Stopping Clam AntiVirus Daemon: [ OK ]
[hubble:root]:(~)# time service clamd start
Starting Clam AntiVirus Daemon: [ OK ]
30.00user 2.06system 0:32.07elapsed 99%CPU (0avgtext+0avgdata 4311168maxresident)k
0inputs+0outputs (0major+500027minor)pagefaults 0swaps
[hubble:root]:(~)# clamdscan --version
ClamAV 0.102.4/25906/Fri Aug 21 15:10:42 2020
[hubble:root]:(~)# cat /var/lib/run/clamav/clamd.pid
32185
[hubble:root]:(~)# ps ax | grep clamd
32185 ? Ssl 0:00 clamd
32344 pts/2 S+ 0:00 grep --color clamd
[hubble:stock]:(~)# rpm -q -f /sbin/init
SysVinit-2.86-4mdk
[hubble:stock]:(~)#

--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net


_______________________________________________

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
Re: ClamAV 0.103.0 release candidate - systemd service start fails [ In reply to ]
I have reproduced this error, and am currently working on a fix. See https://bugzilla.clamav.net/show_bug.cgi?id=12597.

We made a change to create PID files before dropping privileges so that an unprivileged user cannot change the PID file and have the service manager kill the wrong process.

Since there are still conditions that could cause the child process initialization to fail, the parent process waits for a signal that the child process is initialized to exit, so that it can report an accurate exit status. When the child drops privileges, it is not able to send SIGINT to the parent. I am currently working on a patch to have the parent drop privileges so that it can be signaled by the child.

Thanks,
Andy



________________________________

From: clamav-users <clamav-users-bounces@lists.clamav.net> on behalf of Michael Orlitzky via clamav-users <clamav-users@lists.clamav.net>
Sent: Friday, August 21, 2020 12:20 PM
To: clamav-users@lists.clamav.net <clamav-users@lists.clamav.net>
Cc: Michael Orlitzky <michael@orlitzky.com>
Subject: Re: [clamav-users] ClamAV 0.103.0 release candidate - systemd service start fails

On 2020-08-21 11:29, Arjen de Korte via clamav-users wrote:
>
>> # ps ax | grep clamd
>> 7436 ? Ssl 0:25 sbin/clamd
>
> # ps ax | grep clamd
> 7840 pts/2 S+ 0:00 /usr/sbin/clamd --debug
> 7841 ? Ssl 0:38 /usr/sbin/clamd --debug
>
> Previously I've waited for more than an hour, no change. The process
> running under root never exits.
>

Ok, I can confirm this! After setting

User clamav

in clamd.conf, I've seen the root process get stuck as well. That's not
an intended effect of the PID file change.


_______________________________________________

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