Hi, I could not deal with a solaris bug I encountered, so I don't release any snapshots now. What I have done since last release, and what's available in cvs: 1999-06-08 Balazs Scheidler <bazsi@balabit.hu> * named pipes work now with the file driver (I may introduce a pipe driver later on, which could be an alias for "file") * fixed a bug in log_handler.destroy handling * changed -HUP handling, it reverts to the old config if the new cannot be initialized * changed afsocket_dest_reopen to be a general callback, capable of reinitializing any log_handler (and moved to destinations.c) * debian control file fixes (reported by Peter Gervai, grin@tolna.net) * internal source driver checks if used once * fixed a bug in syslog-ng.h, which used the config file in cwd even if debugging was turned off 1999-06-06 Balazs Scheidler <bazsi@balabit.hu> * added reference documentation to doc/syslog-ng.html * changed the parser, so IDENTIFIER's can always be quoted using quotation marks (") There have been some bugfixes, and the documentation was added to the tree. I have a quite major problem on solaris. As it seems the way syslog-ng exits the parent process when backgrounding itself conflicts with solaris thread libraries. The parent process waits until the configuration is initialized, so no log messages sent directly after syslog-ng backgrounds itself is not lost. This is accomplished via the TERM signal: parent: wait until term signal arrives child: initialize config send SIGTERM to parent The parent exits without problems, but the child gets a SIGABRT for some unknown reason. If I use the -d switch, which prevents syslog-ng to background itself, everything works fine. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi@balabit.hu
parent: wait until term signal arrives
child: initialize config send SIGTERM to parent
Maybe I'm missing something, but why don't you initialize the config *before* forking? Then all the parent needs to do is exit.... (I assume you set the parent's SIGCHLD handler to ignore and that the child removes itself from the parent's process group.... though even that you can do before forking.) Cheers, Rob
parent: wait until term signal arrives
child: initialize config send SIGTERM to parent
Maybe I'm missing something, but why don't you initialize the config *before* forking? Then all the parent needs to do is exit.... (I assume you set the parent's SIGCHLD handler to ignore and that the child removes itself from the parent's process group.... though even that you can do before forking.)
Because initialization may mean something that cannot be inherited by fork(), for instance door support may create threads etc. I background the child using the following function: void go_background() { pid_t pid; pid = fork(); if (pid == 0) { return; } else if (pid == -1) { werror("Cannot fork(), (%z)\n", strerror(errno)); exit(1); } signal(SIGTERM, sig_term); while (sigtermrecvd == 0) pause(); exit(0); } The child then initializes config and calls the following code: if (do_fork) { set_error_internal(); close(0); close(1); close(2); setsid(); kill(getppid(), SIGTERM); } I don't understand everything about process groups, process leaders and such, but this should work IMHO. If you have a better idea, please don't hesitate to tell me. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi@balabit.hu
participants (2)
-
Balazs Scheidler
-
Robert Loomans