Hi,
I have the same problem (0.65 and devel).
It seems the signal handling isn't sufficient.
In clamd/server.c sighup is set, but it seems it's never really
used to re-open the logfile.
case SIGHUP:
sighup = 1;
- Frank
--
Email: [EMAIL PROTECTED] http://www.tu-chemnitz.de/~fri/
Work: Com
On Tue, 03 Feb 2004 at 13:28:07 +0100, Krištof Petr wrote:
> Tomasz Papszun wrote:
>
> >It may be true, unfortunately.
> >I'd like to stress that, though logrotate and clamd cooperate for me, it
> >may be the effect of restarting clamd, not "SIGHUPping" it:
> >
> >postrotate
> >/etc/init.d
On Tue, 03 Feb 2004 at 13:37:16 +0100, Tarjei Knapstad wrote:
> On Mon, 2004-02-02 at 17:42, Paul Carpenter wrote:
> > I use logrotate on my RedHat system with:
> >
> > /var/log/clamd.log {
> > missingok
> > create 0640 clamav root
> > prerotate
> > /sbin/se
Tomasz Papszun wrote:
It may be true, unfortunately.
I'd like to stress that, though logrotate and clamd cooperate for me, it
may be the effect of restarting clamd, not "SIGHUPping" it:
postrotate
/etc/init.d/clamav-daemon force-reload
endscript
The entry "force-reload" contains 'stop;
On Mon, 2004-02-02 at 17:42, Paul Carpenter wrote:
> I use logrotate on my RedHat system with:
>
> /var/log/clamd.log {
> missingok
> create 0640 clamav root
> prerotate
> /sbin/service clamd stop 2> /dev/null || true
> endscript
> postrotate
>
On Tue, 03 Feb 2004 at 9:57:02 +0200, Tuomo Soini wrote:
> Dennis Skinner wrote:
>
> >Seems to work fine for me. Try the copytruncate option.
>
> Copytruncate is only work-around that bug. Clamd doesn't close logfile
> and open it again as it should when it's getting SIGHUP. And same
> applie
Dennis Skinner wrote:
Seems to work fine for me. Try the copytruncate option.
Copytruncate is only work-around that bug. Clamd doesn't close logfile
and open it again as it should when it's getting SIGHUP. And same
applies to freshclam.
--
Tuomo Soini <[EMAIL PROTECTED]>
Linux and network serv
Tomasz Kojm wrote:
That's not gonna work. I have clamd.log in directory writeable by user
The log file itself must be writeable for clamd not only a directory.
But of course logfile is owned by user clamav group clamav mode 640.
_IT_IS_A_BUG_.
--
Tuomo Soini <[EMAIL PROTECTED]>
Linux and netwo
On Mon, 2004-02-02 at 05:28, KriÅtof Petr wrote:
> Yes . It is known issue. I reported it many times in last 6 month, but
> developers
> ignores it. Log rotating never worked.
>
> Petr
Seems to work fine for me. Try the copytruncate option.
/usr/clamav/log/clamd.log {
create 600 clamav cla
On Tue, 03 Feb 2004 00:05:33 +0200
Tuomo Soini <[EMAIL PROTECTED]> wrote:
> Tomasz Kojm wrote:
>
> > You're right. Petr: the solution to your problem is to change the
> > owner of the log file so clamd is able to open it for r/w.
>
> That's not gonna work. I have clamd.log in directory writeable
Tomasz Kojm wrote:
You're right. Petr: the solution to your problem is to change the owner
of the log file so clamd is able to open it for r/w.
That's not gonna work. I have clamd.log in directory writeable by user
clamav and logrotate script creates logfile owned by user clamav group
clamav and
Tomasz Kojm wrote:
That could be it. If clamav opens the log file initially as root, but
when it receives the HUP signal it may be trying as the clam user.
You're right. Petr: the solution to your problem is to change the owner
of the log file so clamd is able to open it for r/w.
Doesnt help.
[
On Mon, 2 Feb 2004 09:43:48 -0500 (EST)
"Christopher X. Candreva" <[EMAIL PROTECTED]> wrote:
> On Mon, 2 Feb 2004, Daniel Wiberg wrote:
>
> > Just a thought, user clamav does not have write permissions in the
> > log directory, so logrotate, which I guess runs as root should
> > create the new fi
I use logrotate on my RedHat system with:
/var/log/clamd.log {
missingok
create 0640 clamav root
prerotate
/sbin/service clamd stop 2> /dev/null || true
endscript
postrotate
sleep 5
/sbin/service clamd start 2> /dev/null || true
I'm having an identical problem with logrotation. Except it is not
with clamd but rather with my maillog. It did not start until I began
using mailgraph.pl. I can't figure it out either. I don't think that
the problem is related to either clamd or mailgraph.
Where does one get "support" for logro
On Mon, 02 Feb 2004 at 14:53:10 +0100, Daniel Wiberg wrote:
> On Mon, Feb 02, 2004 at 02:27:18PM +0100, Tomasz Papszun wrote:
> > I didn't look at the sources but I've always thought that log rotating
> > is done different way.
> > The current logfile is _moved_ to other filename, not removed (dele
On Mon, 2 Feb 2004, Daniel Wiberg wrote:
> Just a thought, user clamav does not have write permissions in the log
> directory, so logrotate, which I guess runs as root should create the new
> files also, owned by user clamav.
>
> Or did I overlook something?
That could be it. If clamav opens the
Tomasz Papszun wrote:
On Mon, 02 Feb 2004 at 7:43:28 -0600, Daniel J McDonald wrote:
I was talking about that "_initially_" aspect. What happens later with
old logfiles is out of clamd interest.
That's not the problem. Problem is that kill -HUP doesn't affect clamd
at all. It doesn't release old
On Mon, 02 Feb 2004 at 7:43:28 -0600, Daniel J McDonald wrote:
> On Mon, 2004-02-02 at 07:27, Tomasz Papszun wrote:
> > On Mon, 02 Feb 2004 at 14:03:55 +0100, Krištof Petr wrote:
> > > Tomasz Kojm wrote:
>
> > The current logfile is _moved_ to other filename, not removed (deleted).
> Initially, y
On Mon, Feb 02, 2004 at 02:27:18PM +0100, Tomasz Papszun wrote:
> I didn't look at the sources but I've always thought that log rotating
> is done different way.
> The current logfile is _moved_ to other filename, not removed (deleted).
> Due to this, the logfile is still open and new entries can b
Tomasz Papszun wrote:
I didn't look at the sources but I've always thought that log rotating
is done different way.
The current logfile is _moved_ to other filename, not removed (deleted).
Due to this, the logfile is still open and new entries can be written to
it. Then on reload or restart, the h
On Mon, 2004-02-02 at 07:27, Tomasz Papszun wrote:
> On Mon, 02 Feb 2004 at 14:03:55 +0100, Krištof Petr wrote:
> > Tomasz Kojm wrote:
> The current logfile is _moved_ to other filename, not removed (deleted).
Initially, yes, but a SIGHUP is done to make the application re-open the
log files. The
On Mon, 02 Feb 2004 at 14:03:55 +0100, Krištof Petr wrote:
> Tomasz Kojm wrote:
>
> >Unfortunately, I'm not familiar with logrotate. But will check the HUP
> >handling tonight. Sorry !
> >
>
> Tomasz,
>
> you dont need to lose time with logrotate. This is simple step by step,
> how to test it:
Tomasz Kojm wrote:
On Mon, 02 Feb 2004 11:28:59 +0100
Krištof Petr <[EMAIL PROTECTED]> wrote:
Yes . It is known issue. I reported it many times in last 6 month, but
developers
ignores it. Log rotating never worked.
Unfortunately, I'm not familiar with logrotate. But will check the HUP
ha
On Mon, 02 Feb 2004 11:28:59 +0100
Krištof Petr <[EMAIL PROTECTED]> wrote:
> Yes . It is known issue. I reported it many times in last 6 month, but
>
> developers
> ignores it. Log rotating never worked.
Unfortunately, I'm not familiar with logrotate. But will check the HUP
handling tonight. Sor
Robert S wrote:
I am using logrotate to rotate my clamd logs. I have an entry called "clam"
in /etc/logrotate.d which looks like this:
/var/log/clam/clam*.log {
sharedscripts
postrotate
/bin/kill `/usr/bin/cat /var/run/clamd/clamd.pid` 2>/dev/null
/usr/local/sbin/clamd
ends
26 matches
Mail list logo
