versatica / OverSIP

OverSIP: the SIP framework you dreamed about
http://oversip.versatica.com
Other
340 stars 68 forks source link

Adds a --no-daemonize option #91

Open colinmorelli opened 8 years ago

colinmorelli commented 8 years ago

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.

colinmorelli commented 8 years ago

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 /dev/null and use syslog instead.

Thoughts?

saghul commented 8 years ago

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.

colinmorelli commented 8 years ago

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.

saghul commented 8 years ago

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.

colinmorelli commented 8 years ago

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.

ibc commented 8 years ago

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.

saghul commented 8 years ago

I can easily make a change to disable syslog in favor of using stdout in the foreground.

This would be the only acceptable way to log when not in the background IMHO. But it's up to @ibc to decide.

colinmorelli commented 8 years ago

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.

mbrodala commented 6 years ago

What is the current status here? I assume this is essential to get OverSIP running in a Docker container.

ibc commented 6 years ago

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.