hi all,
is it safe to call openlog() with the LOG_CONS flag *before* becoming a daemon? Daemonization involves fork(); setsid(); fork() sequence, and it would like to get a detailed message to the system log if the daemonization fails in one of the child processes. Most daemonization code samples call openlog() after daemonization, is there any special reason for not doing it beforehand?
br,
risto
openlog and closelog are optional. If you really have an important message to send during "daemonization" just call syslog, it will create the fd for the syslogd connection.
Otherwise calling openlog just creates more open descriptors you do not really need.
Short answer: call syslog for fatal errors, otherwise don't do it until you're set up.
With a specific openlog and closelog, file descriptors are deliberately created and binded to the log daemon,
with a syslog call internally descriptor is created and bound to sys log daemon.
When openlog call is made, it would become necessary to call closelog;
( as closing all the opened descriptors before terminating the code is a good practice )
include closelog in the list of house keeping operations, as it might be needed during a crash or an abnormal exit.
Whilst, this need is removed when syslog call is made! 
Correct me if I'm wrong, but openlog() is required if you wish to subsequently syslog() with a facility other than LOG_USER (i.e. if you wish your messages to be processed with facility of LOG_AUTH or LOG_DAEMON, etc.).
Or, as in the original poster's case, if you want additional flags such as LOG_CONS to apply, you must use openlog() to set them.
In reference to the original poster's question, I do not know this for certain, but I suspect any file descriptors or other details would be inherited by the child (and grandchild) processes and be unaffected by the rest of the "daemonization" procedure.
POSIX 1b specifications indicate that openlog is optional. syslog will create the fd if none exists.
I do not know what happens on really older systems. As I remember, syslog did work for most log types.
Thanks to all who have responded!
In order to become a daemon, the process must give up its controlling terminal with fork(); setsid(); fork(), and I was initially just worried that the LOG_CONS option might have an unwanted side-effects for that, especially if you log a message between the first and second fork(). I know that according to posix LOG_CONS should not allocate a controlling terminal to the process (see http://www.opengroup.org/onlinepubs/009695399/functions/syslog.html\); however many implementations achieve this by forking a separate process during syslog(). What about glibc that does not call fork() during syslog()? I am asking this just out of curiosity, since if the program is going to log something between two fork()'s, it could only be a message about failure of setsid() or the second fork() -- which mean that the process will terminate anyway.
Anyway, it seems that the safest workaround is to drop LOG_CONS altogether, since in that case calls to openlog() and syslog() wouldn't have a chance of having any adverse effect on giving up a controlling terminal (please correct me if I am wrong).
br,
risto