Opened 9 years ago

Closed 3 weeks ago

Last modified 3 weeks ago

#36 closed defect (fixed)

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

Reported by: guest Owned by: diver
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 9 years ago by guest

  • Priority changed from minor to major

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

comment:2 Changed 9 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 9 years ago by herwigb

  • Priority changed from major to blocker

This is becoming a a major annoyance...

comment:4 Changed 8 years ago by ydario

  • Milestone set to Samba Server for OS/2 1.0.1

comment:5 Changed 7 years ago by herwigb

  • Version set to 3.0.26a

comment:6 Changed 7 years ago by diver

  • Milestone changed from Samba Server for eCS (OS/2) 1.0.1 to Samba 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 7 years ago by diver

  • Priority changed from blocker to major

comment:8 Changed 5 years ago by herwigb

  • Priority changed from major to critical
  • Version changed from 3.0.26a to 3.3.x

comment:9 Changed 5 years ago by herwigb

  • Owner changed from psmedley to diver
  • Status changed from new to assigned

comment:10 Changed 5 years ago by herwigb

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 3 years ago by diver

  • Milestone changed from Samba Server for eCS (OS/2) 1.1.x to Samba Server for eCS (OS/2) 1.2.x

comment:12 Changed 2 years ago by diver

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

comment:13 Changed 2 years ago by diver

  • Priority changed from critical to Feedback Pending

comment:14 Changed 5 weeks ago by herwigb

  • Priority changed from Feedback Pending to blocker

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

comment:15 Changed 4 weeks ago by herwigb

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 3 weeks ago by dmik

  • Resolution set to fixed
  • Status changed from assigned to closed

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 3 weeks ago by dmik

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

Note: See TracTickets for help on using tickets.