The default logging format is kind of sucky right now. The main issue is that each event is spread across two lines.
If you grep through a log file for a user ID, hostname, or share name you find it, but since the date and time are on a different line you can't co-ordinate events easily. At the very least each event should be on one line.
Since 4.x is changing so many other things, a small tweek to the logging format to help out sysadmins (and their monitoring tools) should at least be considered.
Andrew, do you think we should try to work on that?
This would require consensus on the mailing list first. Most developers tend to run with 'debug timestamp = no' set anyway (which is perhaps why the function name is included 'twice' so often.
We had now some propositions on the mailing list. Would we take for now the approach of Volker (http://lists.samba.org/archive/samba-technical/2007-August/055237.html)? What do you say?
We generally want to be compatible with Samba3 on stuff like this, so if there are patches that can be ported forward, I'll be happy to review them.
Is this issue concerning yet?
(In reply to comment #4)
> We generally want to be compatible with Samba3 on stuff like this, so if there
> are patches that can be ported forward, I'll be happy to review them.
Why is it necessary to be compatible with Samba3? If it's not possible to break compatibility during a major version jump, when would it be possible? At some point you need to fix architectural issues, and 3.x to 4.x is a great opportunity IMHO.
I think I close this for now with "WONTFIX" since this really needs some discussion on the technical list first. Otherwise we come no further here.
I suggest you:
- Write an email to "email@example.com" about this issue and state there your opinion about the current format (why it is bad) and give an idea how the new one should look like
- Then wait for responses from team members
- If there is interest to switch to a new format, it would be really nice if you could provide patches (I think for both s3 and s4 - since in this area, as abartlet stated, we prefer to be consistent).