{"action":"created","issue":{"url":"https://api.github.com/repos/fail2ban/fail2ban/issues/1139","labels_url":"https://api.github.com/repos/fail2ban/fail2ban/issues/1139/labels{/name}","comments_url":"https://api.github.com/repos/fail2ban/fail2ban/issues/1139/comments","events_url":"https://api.github.com/repos/fail2ban/fail2ban/issues/1139/events","html_url":"https://github.com/fail2ban/fail2ban/issues/1139","id":97735128,"number":1139,"title":"Support foreground with fail2ban-server","user":{"login":"Glandos","id":297578,"avatar_url":"https://avatars.githubusercontent.com/u/297578?v=3","gravatar_id":"","url":"https://api.github.com/users/Glandos","html_url":"https://github.com/Glandos","followers_url":"https://api.github.com/users/Glandos/followers","following_url":"https://api.github.com/users/Glandos/following{/other_user}","gists_url":"https://api.github.com/users/Glandos/gists{/gist_id}","starred_url":"https://api.github.com/users/Glandos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Glandos/subscriptions","organizations_url":"https://api.github.com/users/Glandos/orgs","repos_url":"https://api.github.com/users/Glandos/repos","events_url":"https://api.github.com/users/Glandos/events{/privacy}","received_events_url":"https://api.github.com/users/Glandos/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-07-28T15:25:41Z","updated_at":"2015-07-29T13:59:03Z","closed_at":null,"body":"With the era of new-style init (such as systemd) or daemon managers (such as supervisord), it seems safer to write program that doesn't try to be a daemon itself, since there are a lot of corner cases and pitfalls. Fail2ban seems to do it nicely, however, I see at least two reasons to support a foreground mode:\r\n  * If some platform has some specific initialization pattern, it could be handled by the init/daemon manager.\r\n  * Log management is far easier when the init/daemon manager handles it, usually by fetching the stdout of the launched program. I'm not sure that setting the logtarget to STDOUT with the current daemonizing behavior will be successful.\r\n\r\nIs there any good reason not to support a foreground behavior? Or is it a simple historical thing?"},"comment":{"url":"https://api.github.com/repos/fail2ban/fail2ban/issues/comments/125960786","html_url":"https://github.com/fail2ban/fail2ban/issues/1139#issuecomment-125960786","issue_url":"https://api.github.com/repos/fail2ban/fail2ban/issues/1139","id":125960786,"user":{"login":"yarikoptic","id":39889,"avatar_url":"https://avatars.githubusercontent.com/u/39889?v=3","gravatar_id":"","url":"https://api.github.com/users/yarikoptic","html_url":"https://github.com/yarikoptic","followers_url":"https://api.github.com/users/yarikoptic/followers","following_url":"https://api.github.com/users/yarikoptic/following{/other_user}","gists_url":"https://api.github.com/users/yarikoptic/gists{/gist_id}","starred_url":"https://api.github.com/users/yarikoptic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yarikoptic/subscriptions","organizations_url":"https://api.github.com/users/yarikoptic/orgs","repos_url":"https://api.github.com/users/yarikoptic/repos","events_url":"https://api.github.com/users/yarikoptic/events{/privacy}","received_events_url":"https://api.github.com/users/yarikoptic/received_events","type":"User","site_admin":false},"created_at":"2015-07-29T13:59:03Z","updated_at":"2015-07-29T13:59:03Z","body":"\nOn Wed, 29 Jul 2015, Serg G. Brester wrote:\n\n>    It's a historical thing... To start resp. run it completely as server, we\n>    should move the part of the client functionality, that read config files,\n>    to the server (or better to new thread in server, something like\n>    ConfigReaderThread, that can read/reload/stop/etc and ends hereafter).\n\n>    In any case, the good point would be to make it together with #1121\n\nbetter not. #1121 is just a mere refactoring moving code around and\nproviding entry points, which shouldn't affect any functionality\n(will do right after 0.9.3 release).  Fix for this one would require\nfunctionality changes, so better be done separately after that.\n\nand I thought that it could be done with minimal blood without\nmoving/sharing functionality between client/server, just letting client\nprocess start server separately, do its \"initiation\" dance and\nthen joining the server process (thus remaining in foreground). Didn't\nhave a chance to try.  As such this change would even remain orthogonal\n(independent) of #1121.\n"}}