Opened 16 years ago

Closed 8 years ago

Last modified 8 years ago

#36 closed defect (fixed)

max log file does not work (i.e logfile grows forever)

Reported by: guest Owned by: Silvan Scherrer
Priority: blocker Milestone: Samba Server for eCS (OS/2) 1.3.x
Component: Samba Server Version: Server 3.3.x
Keywords: log file size Cc: herwig.bauernfeind@…

Description

Entering a size limit for the logfiles in smb.conf via max log size is in vain, because Samba tries to rename the file and that fails.

Probably a similar resolution like Ticket #30 and #31 is required.

Change History (17)

comment:1 Changed 16 years ago by guest

Priority: minormajor

I think the bug is located in \source\lib\debug.c, function check_log_size(), line 708 to 715.

comment:2 Changed 16 years ago by guest

Okay, to reproduce the problem, add

max log size = 1000

to the [global] section of smb.conf. Now the logfile should not grow bigger than 1000 kb i.e 1 MB.

Setting the loglevel to 5 (or higher) and running a dir /s /-p from a client against a share full of files should produce a "bigger" logfile within some 30 seconds or so.

comment:3 Changed 16 years ago by Herwig Bauernfeind

Priority: majorblocker

This is becoming a a major annoyance...

comment:4 Changed 16 years ago by Yuri Dario

Milestone: Samba Server for OS/2 1.0.1

comment:5 Changed 15 years ago by Herwig Bauernfeind

Version: 3.0.26a

comment:6 Changed 15 years ago by Silvan Scherrer

Milestone: Samba Server for eCS (OS/2) 1.0.1Samba Server for eCS (OS/2) 1.1.0 alpha

permanant restriction for 1.0.1 (samba code 3.0). we try to find a solution for 1.1.0 (samba code 3.3)

comment:7 Changed 15 years ago by Silvan Scherrer

Priority: blockermajor

comment:8 Changed 13 years ago by Herwig Bauernfeind

Priority: majorcritical
Version: 3.0.26a3.3.x

comment:9 Changed 13 years ago by Herwig Bauernfeind

Owner: changed from Paul Smedley to Silvan Scherrer
Status: newassigned

comment:10 Changed 13 years ago by Herwig Bauernfeind

It looks like this is becoming more an more important again - Samba 3.3.x prodcues more logfiles. I noticed that with loglevel 3 Samba 3.3.15 produced 3GB+ logfiles in 3 days. Especially log.smbd..UNKNOWN is more than 2GB in size and cannot be deleted while smbd is running.

comment:11 Changed 11 years ago by Silvan Scherrer

Milestone: Samba Server for eCS (OS/2) 1.1.xSamba Server for eCS (OS/2) 1.2.x

comment:12 Changed 10 years ago by Silvan Scherrer

I lost track of that? Did we fix it? Or try to fix?

comment:13 Changed 10 years ago by Silvan Scherrer

Priority: criticalFeedback Pending

comment:14 Changed 8 years ago by Herwig Bauernfeind

Priority: Feedback Pendingblocker

we investigated and found out that Samba tries to rename the open file, which is not possoble on OS/2

comment:15 Changed 8 years ago by Herwig Bauernfeind

Reproduction of this is easy. 1.) Add the following to the global section of smb.conf

[global]
    ....
    log level = 10
    max log size = 2

2.) start Samba and access it from a client. smbclient is sufficient. doing 1 or 2 dir on a longer directory will get the size of the logfile beyond the limit.

comment:16 Changed 8 years ago by dmik

Resolution: fixed
Status: assignedclosed

The fundamental problem here is that on OS/2 it is impossible to delete or rename a file which is open. Note that closing the file before renaming is not always enough in this particular case because the file may be open in another process (due to forking which causes open file handles to be inherited or due to logging to the same file explicitly) and there is no easy way to ask another process to close the file

In order to implement the original Samba functionality (that renames the log file to .old upon reaching the max log size limit and then creates a new one from scratch) we would have to serialize calls to the debug print function among processes and to close the log file after each printed message but that would create too much system overhead. A proper solution would be to port the syslog daemon to OS/2 and use its facilities for logging and log rotation (which is free from that problem since all logs would be handled by a single daemon process). Samba already supports logging to syslogd so when we port it we switch to its usage immediately.

For now we just truncate the file when it reaches its max limit if renaming it fails. This is committed in r947. This will lead to a huge debug message loss at times when the size limit is hit (as all previous messages will be deleted, not only the oldest ones) but one can always disable log rotation in smb.conf if full logging is necessary so it was decided as an acceptable solution for the time being.

comment:17 Changed 8 years ago by dmik

Oops, r947 is actually wrong, r948 is the right one.

Note: See TracTickets for help on using tickets.