This isn't a RedHat specific question. The software in question might be used for any Linux distribution. Would it be advisable or inadvisable for my application, to be downloaded by many people I don't know, to write to the following logs in /var/log?
maillog or mail.log
messages
secure
Is there a reason not to do this, and if I do write to these logs, is ordinary file I/O good enough?
Thanks.
Brandon
syslog generally keeps its destination files open:
[root@localhost log]# fuser maillog
maillog: 4648
[root@localhost log]# ps -efa | grep 4648
root 4648 1 0 2012 ? 00:00:01 syslogd -m 0
root 11294 9649 0 16:20 pts/0 00:00:00 grep 4648
[root@localhost log]#
Obviously two programs can't/shouldn't be writing to the same file. There are also syslog-specific reasons for not wanting to do it this way: What if I'm doing a remote syslog? If you're logging directly to files you don't get to take advantage of that and if you want to build that funtionality in yourself then your job is just that much harder. What if the sysadmin wants your logs to go to two different files? etc, etc.
These are the problems the syslog daemon was created to resolve: make a single program broker access to the logging system, then you can solve common problems in one place and in a way that doesn't lead to programs clobbering the work of others.
Most languages have syslog bindings anyways so there's very little reason to want to do it a different way.
Could I write to all three of these logs with syslog, and would it work across most Linux distributions?
You wouldn't be able to specify these particular files (the messages are routed to the destination files based on the facility/priority pair the program assigned to the message). However the files and the facility/priorities that write to them are pretty consistent across most distributions' default configurations, so you can usually be 90% sure of what file your log will end up in. For example, almost all distributions will route a "mail" facility message of any priority to the /var/log/maillog file, anything logged as "authpriv" to /var/log/secure etc. Linux distros don't have to do it that way, but they have adopted similar configurations just to stick with a common convention where possible.
Basically: by design, you won't be able to be sure that some mail-related message you generate will always end up in /var/log/maillog but if you log to the "mail" facility you can just know that /var/log/maillog is where it's going to end up on almost every major Linux distribution.
It won't be a message related to the general purpose of the log, just a message that I want to put there. I assure you I have reason enough to do what I want to do. I just wonder about the difficulty/appropriateness of writing to these logs.
Well you're not going to reliably write to the log files directly, so you might as well disregard that notion out of hand. If it's a message that's unrelated to mail (for example) and you want it grouped with other email messages, you can just log it with the "mail" facility and let the syslog daemon do with it whatever it does with "mail" logs in general, which means they'll generally end up in the same place.
It's honestly not that difficult. To syslog in python:
import syslog
syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_MAIL)
syslog.syslog('Some mail-related log message...')
If you're using regular C then this will be a good reference.
Basically, the whole thing is over with by the third line no matter what language you're writing your program in.
Thank you.
What I would write is beginning of day markers at midnight. My issue is that these logs never show the year. Ordinarily, this causes no confusion, since the year is quite obvious. For machines that may be down for years or months at a time, there could occasionaly be ambiguity as to the year of a log entry. Therefore, for reasons connected with my application, I am considering writing a 12:00 AM delimiter, which includes the year, to remove all doubt as to exactly what day, including year, every message belongs to.
How the date is formatted is decided by the syslog daemon which is in turn decided by how the daemon is configured. If the customer/clients wants that level of precision, they should reconfigure syslog to that it doesn't truncate the date like that. Doing something else might fix their problem with your application but still leaves that same level of ambiguity for all other logging going on with their system. So even they don't want to fix it another way. Just let them know that it's their syslog daemon that's doing the truncating and not your program.
Different distributions have different types of syslog daemons with sometimes slight differences so this is probably best left at a "You need to fix your syslog then" coming from your end. You can research the steps required for the various daemons and give them as helpful advice but I wouldn't really bother myself with more than that. Most of the popular syslog daemons (like rsyslog and syslog-ng) typically have some sort of "template" directive where the admin can specify the format and the fields they want to show up in their logs. Most daemons will also have an option for setting a default template, which is usually sufficient for making sure files show up in the new format (after a daemon reload).
I say usually because the admin could have some custom configuration going on where they've defined a particular format for the /var/log/maillog file or something. Which is another reason why you're in a better position to make suggestions to the admins rather than try to fix it yourself somehow.
Your solution does seem to be decent enough, but it's probably better for them to have the date on the same line as the message so they don't have to scrollback.
It's good to know that I could change my own time stamp format with syslog, but I have no power to advise the customers to do anything. They just buy the product and have environments all over the spectrum. My present task is just to read the logs and know when the messages were written.
So, I guess you're saying that it's okay to write to the various logs as long as I do it through syslog.
Yeah you'll have to write syslog in order for it to end up in those files. Your idea of just printing a banner is alright I just wouldn't do it since it would be to solve a problem that the customer should already be able to easily fix themselves. Obviously, it's all about what you feel comfortable asking of your customers, so take what I say with a grain of salt.
Cheers,
Joel
Thank you for your excellent replies. You know a lot and your answers have been helpful.