OverSIP icon indicating copy to clipboard operation
OverSIP copied to clipboard

Adds a --no-daemonize option

Open colinmorelli opened this issue 9 years ago • 10 comments

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 avatar Jun 14 '16 22:06 colinmorelli

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?

colinmorelli avatar Jun 15 '16 14:06 colinmorelli

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.

saghul avatar Jun 15 '16 14:06 saghul

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.

colinmorelli avatar Jun 15 '16 14:06 colinmorelli

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.

saghul avatar Jun 15 '16 14:06 saghul

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.

colinmorelli avatar Jun 15 '16 14:06 colinmorelli

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.

ibc avatar Jun 15 '16 14:06 ibc

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.

saghul avatar Jun 15 '16 14:06 saghul

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.

colinmorelli avatar Jun 15 '16 14:06 colinmorelli

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

mbrodala avatar Mar 07 '18 15:03 mbrodala

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.

ibc avatar Mar 07 '18 16:03 ibc