On Mon, 27 Jun 2016 13:03:09 +0300 Peter Pentchev wrote:
>
> Hi,
>
> Thanks for the suggestion, and thanks for the provided sample file!
> Also, apologies for not replying sooner.
>
> Actually, I've been thinking about providing a native systemd unit /
> service file for quite some time now, and there's just one thing that
> has stopped me from doing that: the SysV init script provided by
> upstream and used in the Debian package allows the users to have more
> than one stunnel service defined in separate /etc/stunnel/*.conf files
> and start/stop individual services by running
>
> /etc/init.d/stunnel4 start|stop filename
>
> ...thereby starting/stopping the stunnel instance defined in
> the /etc/stunnel/filename.conf file.
>
> However... your bug report made me stop and think for a second, and
> I figured out (and then tested it) that this does not actually work as
> intended on a systemd installation, since there is a file in /lib/lsb/
> that redirects all /etc/init.d/* calls to systemctl invocations; well,
> systemctl then figures out that there is no systemd service file and
> runs the /etc/init.d/ script again, but by this time the "filename"
> argument has been long forgotten, and the invocation starts or stops
> all of the tunnels defined in /etc/stunnel/*.conf files.
Hello,
Hopefully clicking reply in the web UI routes this to the correct place.
I've been using a systemd unit file for stunnel4 that *does* support
essentially the same thing as the init.d script.
Consider:
[Unit]
Description=Universal SSL tunnel for network daemons (%i)
After=network.target
After=syslog.target
[Service]
Type=forking
ExecStart=/usr/bin/stunnel4 /etc/stunnel/%i.conf
PIDFile=/var/lib/stunnel4/redis.pid
TimeoutSec=600
Restart=always
PrivateTmp=yes
[Install]
WantedBy=multi-user.target Alias=stunnel4.service
---
Starting a specific stunnel with this is achieved with
systemctl start stunnel4@<name>.service
Within the systemd unit file, all occurrences of %i are replaced with
<name>.
I think this meets the requirements you described. It even allows enabling
and disabling specific stunnels for start at boot time.
>
> Of course I know that I can run /etc/init.d/stunnel4 with the env var
> _SYSTEMCTL_SKIP_REDIRECT set to a non-empty string, but even this does
> not really work as intended: if I start a new stunnel instance this way,
> it will not be in the /system.slice/stunnel4.service cgroup, and this
