C syslog.h: is closelog() necessary?

zirias@

Developer
When logging via syslog, I can use openlog() to configure a few things. It doesn't return anything (like, e.g., a handle), so I guess whatever I pass is stored in static memory.

Now, there's also a closelog() function, and all syslog(3) has to say about it is
The closelog() function can be used to close the log file.

So far, so obvious and vague.

Could anyone tell me what this function actually achieves, and what might be a consequence if I never call it, or if I call openlog() twice?
 
I RTSL and fgrep -rl closelog * in /usr/src shows it's used much. FMLU it is defined in lib/libc/gen/syslog.c:
C:
void
closelog(void)
{
        THREAD_LOCK();
        if (LogFile != -1) {
                (void)_close(LogFile);
                LogFile = -1;
        }
        LogTag = NULL;
        status = NOCONN;
        THREAD_UNLOCK();
}
The consequence is that the log file is open when you miss to call closelog()?
 
This still isn't too helpful cause, whatever LogFile is in this code snippet, it isn't a file. Mabe I have to dig into the source myself to answer this question…
 
It's the file descriptor: view +/LogFile lib/libc/gen/syslog.c:
C:
static int      LogFile = -1;           /* fd for log */
 
Sure, but syslog should not access any actual file directly?

So, maybe the fd for the socket used. It's still somewhat unclear ;)
 
When logging via syslog, I can use openlog() to configure a few things. It doesn't return anything (like, e.g., a handle), so I guess whatever I pass is stored in static memory.

Now, there's also a closelog() function, and all syslog(3) has to say about it is


So far, so obvious and vague.

Could anyone tell me what this function actually achieves, and what might be a consequence if I never call it, or if I call openlog() twice?
No consequences. Opening the log only achieves settings for the handling of logging. You can call openlog every time you call syslog if you want to. You can, likewise, not call it at all. The clue is in the LOG_NDELAY.
Same goes for closelog. I guess it's all for symmetry.
 
Sure, but syslog should not access any actual file directly?

So, maybe the fd for the socket used. It's still somewhat unclear ;)
Syslog is socket based, the file descriptor is a socket. The calls for syslog are, it seems, to trick you into thinking you're actually using a file?
 
Syslog is socket based, the file descriptor is a socket. The calls for syslog are, it seems, to trick you into thinking you're actually using a file?
No, I'm well aware syslog uses a local or UDP socket, just unsure about the handling in the lib and why closelog() exists at all? The idea was that maybe, not calling it would leave a fd open or even something allocated on the heap ;)

edit: I currently use this little adapter for directing my logs to syslog: https://github.com/Zirias/remusock/blob/master/src/bin/remusockd/syslog.c – so, no call to closelog() so far. Good to know I don't have to add it ;)
 
I often wondered about closelog and its use (or non-use). It serves no real purpose, other than to release the descriptor, but as most programs I've ever been involved with that use syslog, never close it and leave it to be cleaned up by the OS when the process exits.
Some programs use it in signal handling functions to change logging mode etc. So you closelog then openlog with new settings, for example.

So it has a purpose but it just not required. In fact even close isn't required if you just need a file open for the entire life of the program.
 
Well, the question remains, does it serve any purpose when calling it before another openlog() with different flags for example? Hypothetical so far, cause my programs don't regularly change flags at runtime, but would be interesting to know ;)

Anyways, the manpage just isn't helpful here. :-/
 
I guess manpages are known for their terseness.

Either way, if you don't call closelog before a new openlog, then all it does is ... wait for it... nothing.:)
 
Back
Top