Errorlog opening/closing
Closed this issue · 3 comments
The error log, if opted, opens after a bunch of possibilities for the server to exit with error due to config/spin-up issues; because of that we loose the details about those issues, if we solely trying to rely on the error log for troubleshooting:
Line 1707 in 949da5e
Thus, to question to investigate:
- Is it possible to move the error log opening earlier in the server setup, like doing it just after the configuration read?
- For our usecase like library, is there an easy way to hack the code to open the error log just once, before starting the server, and keep it open, no matter whether we shutdown / re-launch the server repeatedly?
... probalbly, we don't even have to rely on the errorlog option of lighttpd config, but rather hook up into the default error output stream, and redirect that to the file where we need it, (semi-)externally from the server library?
log_error(srv->errh, FILE, LINE, "Opening errorlog failed. Going down.");
If lighttpd can not open the configured error log, how do you propose opening the error log earlier (and failing) and then writing the error trace to the (failed-to-open) error log about how lighttpd failed to open the error log? Does not compute.
lighttpd can be run in test-config pre-flight mode on the command line with "-tt". You should run that and capture any trace to STDERR_FILENO. lighttpd writes early startup trace to STDERR_FILENO.
If the config test succeeds, then running lighttpd with the same args is very likely to pass initial setup phase and get to the point where it opens the error log and redirects further trace to the error log, unless the error is opening the configured error log.
Depending on your application, you can open the error log on STDERR_FILENO and then simply not configure server.errorlog in lighttpd, and lighttpd will continue to log error trace to the inherited STDERR_FILENO.
- For our usecase like library, is there an easy way to hack the code to open the error log just once, before starting the server, and keep it open, no matter whether we shutdown / re-launch the server repeatedly?
On some platforms, you can open the error log yourself, and then set server.errorlog = "/dev/fd/999" (if the error log is opened on fd 999). However, that won't change where lighttpd sends error trace (STDERR_FILENO) during the initial setup phase.
If there are specific errors that you want to detect, such as opening the error log, you might attempt to open the error log (and then close it) before calling into lighttpd code.
- Is it possible to move the error log opening earlier in the server setup, like doing it just after the configuration read?
Why don't you intercept the error log code using one of the options we discussed some months back?
Another alternative is to allocate your own errh and use log_set_global_errh() after server_init(), but note that the allocated errh will be freed in server_free()
Hi @gstrauss , thanks for passing by and commenting on this one! 😃 I actually should have closed this ticket earlier, as after logging it as a note for myself, I figured out the same what you suggest:
Depending on your application, you can open the error log on STDERR_FILENO and then simply not configure
server.errorlog in lighttpd, and lighttpd will continue to log error trace to the inherited STDERR_FILENO.
So... just re-directing stderr to a file (or back) the first thing in my "library server launch entry-point" works fine for me. Sure, probably, there are scenarios when even this fails, but whatever... the only real issue I have encountered so far, and still trying to figure out, very rarely on Android, if server shutdowns gracefully (presumably) and tries to immediately re-launch again on the same address/port, it fails as the port is busy, and it the port stays occupied if it tries to re-launch again. That was exactly the issue I was trying to triage when looking into this error log stuff, and with my stderr redirection to a file, and sending this file along with crash from user devices into to a remote error-tracing system, I was able to confirm the nature of the problem; and, I guess, most probably this issue has little to do with the server itself.