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

[guest]

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.

[guest]

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

[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.

[Herwig Bauernfeind]

This is becoming a a major annoyance...

[Silvan Scherrer]

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

[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.

[Silvan Scherrer]

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

[Herwig Bauernfeind]

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

[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.

[dmik]

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.

[dmik]

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