Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add systemd unit file #156

Open
robinbowes opened this issue Mar 12, 2015 · 6 comments
Open

Add systemd unit file #156

robinbowes opened this issue Mar 12, 2015 · 6 comments

Comments

@robinbowes
Copy link

I'm deploying on CentOS 7 - I'd like a systemd unit file. I will craft one and send a PR, and modify the spec file to use it.

@dlundquist
Copy link
Owner

@robinbowes You might consider using the package from Fedora: http://pkgs.fedoraproject.org/cgit/sniproxy.git/tree/

@robinbowes
Copy link
Author

Aha, that's useful, thanks.

Any chance you can backport their files into your repo so building from source produces the same result?

R.

@jornane
Copy link

jornane commented Feb 9, 2016

I use the following unit file, which is slightly different from the one provided in the fedora package:

/usr/lib/systemd/system/sniproxy.unit

[Unit]
Description=Transparent TLS proxy
Documentation=https://github.com/dlundquist/sniproxy
After=syslog.target
After=network-online.target

[Service]
Type=forking
PIDFile=/var/run/sniproxy.pid
ExecStart=/usr/sbin/sniproxy
Restart=always

[Install]
WantedBy=multi-user.target

Should be disted with an initial configuration that at least contains:

user sniproxy

pidfile /var/run/sniproxy.pid

error_log {
	syslog daemon
	priority notice
}

access_log {
	filename /var/log/sniproxy/access.log
}

Must have a user "sniproxy", must have a directory /var/log/sniproxy (owned by root).

mkdir -p /var/log/sniproxy
adduser -d /var/empty -M -s /sbin/nologin -r sniproxy
  • update 2019, no longer need /var/run/sniproxy directory, write pid directly in /var/run

@adamel
Copy link

adamel commented Apr 15, 2017

@jornane, never use Type=forking or PIDFile unless you absolutely have to (due to hard-to-change legacy daemons). It just introduces race conditions and a risk that systemd will track the wrong PID.

Use Type=simple and sniproxy -f, and omit the pidfile directive from sniproxy.conf.

@robinbowes
Copy link
Author

I had a discussion with someone with better knowledge than me who persuaded me that Type=forking was always the safest choice as it works with badly-behaved daemons.

I seem to recall his reasoning was that systemd uses process groups to correctly identify the daemon process.

I can't find the discussion anywhere, but I was persuaded at the time and don't have a problem with Type=forking any more.

R.

@flokli
Copy link

flokli commented Jan 2, 2020

@robinbowes Type=forking allows to better distinguish between still starting and running daemons.

Probably even nicer would be supporting sd_notify: https://www.systutorials.com/docs/linux/man/3-sd_notify/.

That way, systemd could detect hangs and restart the service automatically by using the software/service watchdog functionality: http://0pointer.de/blog/projects/watchdog.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants