-
Notifications
You must be signed in to change notification settings - Fork 68
Adds a --no-daemonize option #91
base: master
Are you sure you want to change the base?
Adds a --no-daemonize option #91
Conversation
Just to add here - I've gone back and forth on what to do with logging. On the one hand, it's helpful for development purposes to dump logs to stdout. On the other hand, the actual production use case for this feature is more to be used with process monitors and/or docker and the like, at which point the user will likely just pipe stdout to Thoughts? |
Process monitors (or applications acting as such) which run applications in the foreground such as Docker or systemd typically capture stdout and divert it wherever. So I'd say that when running in foreground mode all logging should go to stdout. |
Yes, @saghul - but in the case of docker, for example, it actually just dumps all stdout to a single docker-managed file by default, and doesn't rotate it (unless that has changed recently). This makes it easy to run yourself out of disk space if you don't realize what it's doing. Do you think existing syslog behavior should be preserved in addition to stdout? Or just stdout? That might become confusing for the user. |
You can use the syslog log driver in Docker and send all your container output to a central syslog instance. See: https://docs.docker.com/engine/admin/logging/overview/ IMHO having an application run in the foreground while logging to syslog is an anti-pattern and really unexpected. |
I'm aware there are other options. I was just mentioning the default which can lead to strange behavior. In any case, I can easily make a change to disable syslog in favor of using stdout in the foreground. |
I also think that, when running in foreground, syslog should not be used. BTW: If I made OverSIP today, I wouldn't add syslog support at all, nor daemon capability. |
This would be the only acceptable way to log when not in the background IMHO. But it's up to @ibc to decide. |
Alright I believe the latest commit should have it only log to syslog if daemonized, preferring stdout otherwise. tbh I don't really like how it's working, though. Partially because the construction of the logger is still based on syslog configuration values (to preserve backwards compatibility). Also partly because it just feels a little ugly. |
What is the current status here? I assume this is essential to get OverSIP running in a Docker container. |
The current status is that I'm not actively maintaining OverSIP, but I'd accept a PR that just removes all the daemon and syslog stuff from OverSIP so it becomes a single process that logs to stdout/stderr. Unfortunately this PR is more complex than that and I cannot guarantee that it works fine. |
This PR adds a simple option for no-daemonize.
It also traps SIGINT in the case of running in the foreground, to allow users to simply control-c in a standard terminal to exit the process.