Red Hat Bugzilla – Bug 429815
logrotate segfaults in logrotate.d/samba
Last modified: 2008-01-24 07:07:25 EST
Description of problem:
Logrotate segfaults during run
Version-Release number of selected component (if applicable):
allow crond to run logrotate, or manually '/usr/sbin/logrotate /etc/logrotate.conf`
/etc/cron.daily/logrotate: line 3: 12579 Segmentation fault
(I believe "line 3" here refers to the /etc/cron.daily/logrotate script, so
doesn't tell us much of anything about what brought it on.)
quietly rotates logs as needed
I've had a lot of trouble with logrotate in /var/log/samba, usually due to the
sheer number of files I'd end up with after logrotate would madly attach more
and more '.1's at the end of empty files and create new ones, and eventually the
wildcard expanded line would just be too long for it. But this time, things
seem to be staying pretty clean, and the number of characters in a `echo
/var/log/samba(/old)?/* | wc` (if I may mix my expressions) only comes to 24807
for the main directory, 8143 for old. This did start happening the first run
after the latest logrotate update (Jan 20 for me).
I have attached the output of a typical run (with -d debugging option). With a
little prompting, I could attach debug output; I've done it before, and just
installed the logrotate-debuginfo package, but don't recall the details of what
to do. Here's a little snippet from using what I've recalled:
Program received signal SIGSEGV, Segmentation fault.
0x0498212b in strlen () from /lib/libc.so.6
#0 0x0498212b in strlen () from /lib/libc.so.6
#1 0x054f1098 in ?? () from /lib/libselinux.so.1
#2 0x0804aa4e in rotateSingleLog (log=0x92ed150, logNum=0, state=0x931460c,
rotNames=0x92f0548) at logrotate.c:1013
#3 0x0804ca01 in rotateLogSet (log=0x92ed150, sip=0xbfda75c4, force=0)
#4 0x0804d2ca in main (argc=Cannot access memory at address 0x3
) at logrotate.c:1529
#5 0x04928390 in __libc_start_main (main=0x804cec0 <main>, argc=3,
ubp_av=0xbfda7aa4, init=0x80513f0 <__libc_csu_init>,
fini=0x80513e0 <__libc_csu_fini>, rtld_fini=0x269940 <_dl_fini>,
stack_end=0xbfda7a9c) at libc-start.c:220
#6 0x080497f1 in _start ()
I also just reinstalled samba, to see if a standard /etc/logrotate.d/samba might
help, since mine had been modified in trying to deal with the aforementioned
problems. It still segfaults the same way. I believe none of my other
logrotate.d files have been changed from the defaults.
I noted similar segfault bugs in the past, but they don't quite seem a match for
this: bug 110683, bug 170904, bug 170955, bug 214572
Created attachment 292612 [details]
logrotate -d output
Please post also your /etc/logrotate.d/samba so I could try to reproduce the bug
And one more question -- do you still have those files with '*.18.104.22.168.1'-like
suffixes somewhere in the olddir? This may be the problem -- some of those file
names might have grown too long and this could have triggered the buffer overflow.
Right now, the logrotate.d/samba is completely vanilla:
For a while, it had looked more like this:
And yes, I spent a *long* time cleaning up all those *.1.1... files, and they're
all gone now.
Oh, and the ones in the olddir are all labeled with the new-style '*-20080120'
style filenames. No exceptions anymore.
So the problem is elsewhere... Please try to upgrade to the new
logrotate-3.7.6-2.2 so I'm sure it's not caused by the SELinux patch (doesn't
look like though) and let me know. Thanks.
OK, 3.7.6-2.2 (from testing, right?) seems to have fixed it. No more segfault
when I run it. Thanks for your help, Tomas.
Hmmm... I'm glad it helped. Although I would be even more glad knowing what
exactly caused the problem. And 3.7.6-2.2 should be in stable already. Maybe
it'll take some time for the mirrors to sync...
I'm closing the bug. Feel free to reopen or file a new one in case any new
problem comes up.
Well, if you're worried about it cropping up again, I'll add one more thing I
noticed towards the end. Running `logrotate -d /etc/logrotate.conf` as an
unprivileged user, who can't read the /var/log/samba directory, did not segfault
at all. (Of course, it also didn't rotate anything.) So apparently, the
directory listing contributes, either directly or indirectly.