I'm setting up a new ubuntu server and it includes stunnel version 5.74. My ultimate goal is to have the service managed by systemd. Things didn't really work out of the box because of the needed configuration file which I was able to use from an existing didn't have the appropriate information in it. So, even though it would start (using initd), when I would try to stop it, it wouldn't. This turned out to be pretty straightforward solve by adding the following to my one and only conf file: setuid = stunnel4 setgid = stunnel4 ; PID file is created inside the chroot jail (if enabled) pid = /var/run/stunnel4/stunnel4.pid While the example file in /usr/share/doc/stunnel4/examples/stunnel.conf-sample had these entries in the file, they were commented out and I wasn't sure if that those were actual defaults, or needed to be uncommented for production. The later seemed to be the case. After fixing that, I was able to use systemctl start/stop as normal, however I noticed that it was being started by the old initd setup. #system status stunnel4 ● stunnel4.service - LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons) Loaded: loaded (/etc/init.d/stunnel4; generated) Active: active (running) since Tue 2026-02-24 20:35:35 CST; 2s ago Invocation: 343fad33bfb949aa8b48285e37c7f05a Docs: man:systemd-sysv-generator(8) Process: 4754 ExecStart=/etc/init.d/stunnel4 start (code=exited, status=0/SUCCESS) Tasks: 4 (limit: 4367) CPU: 192ms CGroup: /system.slice/stunnel4.service So after further searching I found the following files: /usr/lib/systemd/system/stunnel.target /usr/lib/systemd/system/stunnel@.service I executed the command: systemctl enable stunnel@myconffile When I use this command: systemctl start stunnel@myconffile It definitely executes the correct command, but then the whole service shuts down and I get this: ○ stunnel@myconffile.service - TLS tunnel for network daemons - per-config-file service Loaded: loaded (/etc/systemd/system/stunnel@.service; enabled; preset: enabled) Active: inactive (dead) since Tue 2026-02-24 20:44:54 CST; 11s ago Duration: 20.157s Invocation: 46cddb34062b401b87e8516f47b1482b Docs: man:stunnel4(8) Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/attuverse.conf (code=exited, status=0/SUCCESS) Main PID: 5099 (code=exited, status=0/SUCCESS) CPU: 128ms No stunnel service is running. There wasn't anything in the log that I could find that would indicate why it stopped. if I execute this command: /usr/bin/stunnel4 /etc/stunnel/myconffile.conf It works how I would expect it to. For now I'm using the initd initialization, but I would love to get the systemd version running. Anyone have some suggestions? Thanks. Mike
On Tue, Feb 24, 2026 at 05:48:52PM -0900, Mike via stunnel-users wrote:
I'm setting up a new ubuntu server and it includes stunnel version 5.74.
My ultimate goal is to have the service managed by systemd.
[snip]
So after further searching I found the following files:
/usr/lib/systemd/system/stunnel.target /usr/lib/systemd/system/stunnel@.service
It feels like you're doing this on a Debian/Ubuntu installation. Take a look at the /usr/share/doc/stunnel4/README.Debian file; its purpose is to document Debian-specific changes to the installation. In particular, it could have pointed you to the per-config-file services quicker :)
I executed the command:
systemctl enable stunnel@myconffile
When I use this command:
systemctl start stunnel@myconffile
It definitely executes the correct command, but then the whole service shuts down and I get this:
○ stunnel@myconffile.service - TLS tunnel for network daemons - per-config-file service Loaded: loaded (/etc/systemd/system/stunnel@.service; enabled; preset: enabled) Active: inactive (dead) since Tue 2026-02-24 20:44:54 CST; 11s ago Duration: 20.157s Invocation: 46cddb34062b401b87e8516f47b1482b Docs: man:stunnel4(8) Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/attuverse.conf (code=exited, status=0/SUCCESS) Main PID: 5099 (code=exited, status=0/SUCCESS) CPU: 128ms
No stunnel service is running. There wasn't anything in the log that I could find that would indicate why it stopped.
What does `journalctl -u stunnel@myconffile.service` say? And BTW, did you stop any running stunnel4 processes before starting the per-config-file service? G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Quoting Peter Pentchev via stunnel-users <stunnel-users@stunnel.org>:
On Tue, Feb 24, 2026 at 05:48:52PM -0900, Mike via stunnel-users wrote:
I'm setting up a new ubuntu server and it includes stunnel version 5.74.
My ultimate goal is to have the service managed by systemd.
[snip]
So after further searching I found the following files:
/usr/lib/systemd/system/stunnel.target /usr/lib/systemd/system/stunnel@.service
It feels like you're doing this on a Debian/Ubuntu installation. Take a look at the /usr/share/doc/stunnel4/README.Debian file; its purpose is to document Debian-specific changes to the installation. In particular, it could have pointed you to the per-config-file services quicker :)
Most definitely. After reading that file is when I actually started moving in a good direction. :)
I executed the command:
systemctl enable stunnel@myconffile
When I use this command:
systemctl start stunnel@myconffile
It definitely executes the correct command, but then the whole service shuts down and I get this:
○ stunnel@myconffile.service - TLS tunnel for network daemons - per-config-file service Loaded: loaded (/etc/systemd/system/stunnel@.service; enabled; preset: enabled) Active: inactive (dead) since Tue 2026-02-24 20:44:54 CST; 11s ago Duration: 20.157s Invocation: 46cddb34062b401b87e8516f47b1482b Docs: man:stunnel4(8) Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/myconffile.conf (code=exited, status=0/SUCCESS) Main PID: 5099 (code=exited, status=0/SUCCESS) CPU: 128ms
No stunnel service is running. There wasn't anything in the log that I could find that would indicate why it stopped.
What does `journalctl -u stunnel@myconffile.service` say?
And BTW, did you stop any running stunnel4 processes before starting the per-config-file service?
I definitely did. Just did it again to be sure...same result. My hope is that someone else has been running an ubuntu installation and got this running without using the initd stuff.
G'luck, Peter
-- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Wed, Feb 25, 2026 at 05:02:27AM -0900, Mike wrote:
Quoting Peter Pentchev via stunnel-users <stunnel-users@stunnel.org>:
On Tue, Feb 24, 2026 at 05:48:52PM -0900, Mike via stunnel-users wrote:
I'm setting up a new ubuntu server and it includes stunnel version 5.74.
My ultimate goal is to have the service managed by systemd.
[snip]
So after further searching I found the following files:
/usr/lib/systemd/system/stunnel.target /usr/lib/systemd/system/stunnel@.service
It feels like you're doing this on a Debian/Ubuntu installation. Take a look at the /usr/share/doc/stunnel4/README.Debian file; its purpose is to document Debian-specific changes to the installation. In particular, it could have pointed you to the per-config-file services quicker :)
Most definitely. After reading that file is when I actually started moving in a good direction. :)
So I assume you have now read the per-config-file service section in that file... so see below :)
I executed the command:
systemctl enable stunnel@myconffile
When I use this command:
systemctl start stunnel@myconffile
It definitely executes the correct command, but then the whole service shuts down and I get this:
○ stunnel@myconffile.service - TLS tunnel for network daemons - per-config-file service Loaded: loaded (/etc/systemd/system/stunnel@.service; enabled; preset: enabled) Active: inactive (dead) since Tue 2026-02-24 20:44:54 CST; 11s ago Duration: 20.157s Invocation: 46cddb34062b401b87e8516f47b1482b Docs: man:stunnel4(8) Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/myconffile.conf (code=exited, status=0/SUCCESS) Main PID: 5099 (code=exited, status=0/SUCCESS) CPU: 128ms
No stunnel service is running. There wasn't anything in the log that I could find that would indicate why it stopped.
What does `journalctl -u stunnel@myconffile.service` say?
You did not answer this question. However, I just realized something after reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Hi Guys, As a side note, I immensely dislike the way Debian modifies stunnel to make it incompatible with upstream. A good example is how Debian duplicates the functionality of the “include” configuration file option I added over 10 years ago by automagically scanning for *.conf files and starting a separate stunnel daemon for each one. Best regards, Mike
On Wed, Feb 25, 2026 at 03:42:10PM +0100, Michał Trojnara via stunnel-users wrote:
Hi Guys,
As a side note, I immensely dislike the way Debian modifies stunnel to make it incompatible with upstream. A good example is how Debian duplicates the functionality of the “include” configuration file option I added over 10 years ago by automagically scanning for *.conf files and starting a separate stunnel daemon for each one.
That is only what the SysV init script does, and it does that largely for backwards-compatibility reasons. The per-config-file systemd service only starts stunnel with the specified config file. This year, I intend to finally do something I have been putting off for years and years and years because of the complexity of handling backwards compatibility, but it has become much more of a maintenance burden (and much more of a support burden for you, for which I do apologize): I intend to rename the stunnel4 package to, well, stunnel :) This will involve a partial incompatibility anyway, so I will try to smuggle a couple of other changes along with it - like e.g. dropping the SysV init script at all[1]. G'luck, Peter [1] I *know* there are people who will object to that. -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Quoting Michał Trojnara via stunnel-users <stunnel-users@stunnel.org>:
Hi Guys,
As a side note, I immensely dislike the way Debian modifies stunnel to make it incompatible with upstream. A good example is how Debian duplicates the functionality of the “include” configuration file option I added over 10 years ago by automagically scanning for *.conf files and starting a separate stunnel daemon for each one.
Best regards, Mike
Frankly, I didn't get any good vibes from using stunnel in the ubuntu setup. It did work with the initd setup, but there was really no info on how I might set it up on my server. Not your fault. I'll see what I can do to influence upstream in management of the config to use systemd more directly. So it did work out of the box using my previous config file, but I'm unclear if there was any intention of how it was to be implemented. Mike
Quoting Peter Pentchev <roam@ringlet.net>: <snip>
You did not answer this question. However, I just realized something after reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do)
Sorry, about not answering the question. It was the same output as what my previous e-mail had. That aside, adding foreground=yes in the myconffile.conf fixed the issue. I did read that in the README.Debian, but stupidly dismissed that because I wasn't intending to create a per config-file setup. However, I think that file needs updating, and my assumption is that it isn't part of the original package. I'd like to make a PR or some suggestions for changes, what is the best way to go about that? For anyone following, the final solution for me to get systemd and disable the initd on Ubuntu was to do the following: in my config file for stunnel, make these changes: foreground=yes setuid = stunnel4 setgid = stunnel4 pid = /var/run/stunnel4/stunnel4.pid in /etc/default/stunnel4, change ENABLED=1 to ENABLED=0 so that the initd won't start at boot. Maybe we can provide a sample conf to work for Debian/Ubuntu and make good default choices? Mike
On Wed, Feb 25, 2026 at 09:04:49AM -0900, Mike wrote:
Quoting Peter Pentchev <roam@ringlet.net>: <snip>
You did not answer this question. However, I just realized something after reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do)
Sorry, about not answering the question. It was the same output as what my previous e-mail had.
Hm, I would have expected at least some "Starting ...service" and "Stopping ...service" in the output of journalctl (not systemctl), but whatever, it seems the issue was resolved.
That aside, adding foreground=yes in the myconffile.conf fixed the issue.
I did read that in the README.Debian, but stupidly dismissed that because I wasn't intending to create a per config-file setup.
However, I think that file needs updating, and my assumption is that it isn't part of the original package.
If you mean README.Debian, it is part of the Debian/Ubuntu package of stunnel, it is not part of the upstream source, true.
I'd like to make a PR or some suggestions for changes, what is the best way to go about that?
The best way would be, on your Ubuntu system, to run the following command: reportbug stunnel4 ...and then follow the prompts and answer the questions.
For anyone following, the final solution for me to get systemd and disable the initd on Ubuntu was to do the following:
in my config file for stunnel, make these changes:
foreground=yes
As noted in the other messages, this is essential if you run stunnel via the per-config-file systemd service. If you start it as a daemon, foreground=yes would be bad.
setuid = stunnel4 setgid = stunnel4
You do not *need* to activate these, so they are not set by default. There are some situations in which stunnel might need to run as root, e.g. to start other programs from different user accounts instead of only forwarding connections. BTW in your first message you mentioned that you were not sure whether those were the default values or not. That's... interesting, since at the very top of the file there is a header :) ; Sample stunnel configuration file for Unix by Michal Trojnara 1998-2025 ; Some options used here may be inadequate for your particular configuration ; This sample file does *not* represent stunnel.conf defaults ; Please consult the manual for detailed description of available options That said, they are not default values because different people use stunnel for different purposes; in some cases it may need access to private keys created (and maybe even used by) other pieces of software, in other cases it may need to be started and stopped by other pieces of software, so there is no "one size fits all" configuration.
pid = /var/run/stunnel4/stunnel4.pid
So first, you do not need that at all if you run stunnel in foreground mode in a systemd file that uses the "simple" run mode, and second, if you use per-config-file systemd services, you *certainly* do not want them all to use the same PID file - if you need a PID file at all. Only the SysV init script still needs the PID file, and as discussed elsewhere in this thread, the Debian/Ubuntu SysV init script for stunnel is... not perfect and is on its way out.
in /etc/default/stunnel4, change ENABLED=1 to ENABLED=0 so that the initd won't start at boot.
The default Debian/Ubuntu policy for such services is to install them enabled by default. The only change I am going to make to the Debian package in that direction would be, as outlined my other message, to drop the single stunnel4 service at all.
Maybe we can provide a sample conf to work for Debian/Ubuntu and make good default choices?
The default choices are good enough for many people. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Wed, Feb 25, 2026 at 09:06:57PM +0200, Peter Pentchev wrote:
On Wed, Feb 25, 2026 at 09:04:49AM -0900, Mike wrote:
Quoting Peter Pentchev <roam@ringlet.net>: <snip>
You did not answer this question. However, I just realized something after reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do)
[snip]
Maybe we can provide a sample conf to work for Debian/Ubuntu and make good default choices?
The default choices are good enough for many people.
I apologize, that was a bit harsh. What I meant to say here was to reiterate my previous statement that there is no "one size fits all" configuration for stunnel; different people really do need different options, sometimes even for different services on the same system :) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Quoting Peter Pentchev via stunnel-users <stunnel-users@stunnel.org>:
On Wed, Feb 25, 2026 at 09:06:57PM +0200, Peter Pentchev wrote:
On Wed, Feb 25, 2026 at 09:04:49AM -0900, Mike wrote:
Quoting Peter Pentchev <roam@ringlet.net>: <snip>
You did not answer this question. However, I just realized
something after
reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do)
[snip]
Maybe we can provide a sample conf to work for Debian/Ubuntu and make good default choices?
The default choices are good enough for many people.
I apologize, that was a bit harsh. What I meant to say here was to reiterate my previous statement that there is no "one size fits all" configuration for stunnel; different people really do need different options, sometimes even for different services on the same system :)
No worries, I didn't take it harshly... I understand. I was offering my time to create multiple different examples to use in the ways you were talking about. I don't need to do it, since mine is working. But I'm willing to, if you'd like. Thanks again for your help and insight in getting this working the way I wanted. Mike
Quoting Peter Pentchev via stunnel-users <stunnel-users@stunnel.org>:
On Wed, Feb 25, 2026 at 09:04:49AM -0900, Mike wrote:
Quoting Peter Pentchev <roam@ringlet.net>: <snip>
You did not answer this question. However, I just realized something after reading Jochen Bern's reply: did you set `foreground = yes` in your config file? (as the last part of the per-config-file service section says you have to do)
Sorry, about not answering the question. It was the same output as what my previous e-mail had.
Hm, I would have expected at least some "Starting ...service" and "Stopping ...service" in the output of journalctl (not systemctl), but whatever, it seems the issue was resolved.
That aside, adding foreground=yes in the myconffile.conf fixed the issue.
I did read that in the README.Debian, but stupidly dismissed that because I wasn't intending to create a per config-file setup.
However, I think that file needs updating, and my assumption is that it isn't part of the original package.
If you mean README.Debian, it is part of the Debian/Ubuntu package of stunnel, it is not part of the upstream source, true.
I'd like to make a PR or some suggestions for changes, what is the best way to go about that?
The best way would be, on your Ubuntu system, to run the following command:
reportbug stunnel4
...and then follow the prompts and answer the questions.
For anyone following, the final solution for me to get systemd and disable the initd on Ubuntu was to do the following:
in my config file for stunnel, make these changes:
foreground=yes
As noted in the other messages, this is essential if you run stunnel via the per-config-file systemd service. If you start it as a daemon, foreground=yes would be bad.
setuid = stunnel4 setgid = stunnel4
You do not *need* to activate these, so they are not set by default. There are some situations in which stunnel might need to run as root, e.g. to start other programs from different user accounts instead of only forwarding connections.
BTW in your first message you mentioned that you were not sure whether those were the default values or not. That's... interesting, since at the very top of the file there is a header :)
; Sample stunnel configuration file for Unix by Michal Trojnara 1998-2025 ; Some options used here may be inadequate for your particular configuration ; This sample file does *not* represent stunnel.conf defaults ; Please consult the manual for detailed description of available options
That said, they are not default values because different people use stunnel for different purposes; in some cases it may need access to private keys created (and maybe even used by) other pieces of software, in other cases it may need to be started and stopped by other pieces of software, so there is no "one size fits all" configuration.
pid = /var/run/stunnel4/stunnel4.pid
So first, you do not need that at all if you run stunnel in foreground mode in a systemd file that uses the "simple" run mode, and second, if you use per-config-file systemd services, you *certainly* do not want them all to use the same PID file - if you need a PID file at all. Only the SysV init script still needs the PID file, and as discussed elsewhere in this thread, the Debian/Ubuntu SysV init script for stunnel is... not perfect and is on its way out.
in /etc/default/stunnel4, change ENABLED=1 to ENABLED=0 so that the initd won't start at boot.
The default Debian/Ubuntu policy for such services is to install them enabled by default. The only change I am going to make to the Debian package in that direction would be, as outlined my other message, to drop the single stunnel4 service at all.
Maybe we can provide a sample conf to work for Debian/Ubuntu and make good default choices?
The default choices are good enough for many people.
G'luck, Peter
-- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
This is all great feedback. Thanks so much. Mike
Am 25.02.26 um 03:48 schrieb Mike via stunnel-users:
It definitely executes the correct command, but then the whole service shuts down and I get this: Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/ attuverse.conf (code=exited, status=0/SUCCESS)
Off the top of my head: Since you apparently made only minimal changes to the config, chances are that the starting stunnel fork()s, the child puts itself in the background, and the parent exits (proper behaviour for getting fired up by initd). systemd likes to interact with the spawned services (notice when they've terminated abnormally, etc.), so it might expect stunnel *not* to detach itself. "status=0" suggests that stunnel *itself* did *not* see any problem.
if I execute this command: /usr/bin/stunnel4 /etc/stunnel/myconffile.conf
(Is that an actual mismatch, or did you just forget to redact the config file's name above ... ?) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Quoting Jochen Bern via stunnel-users <stunnel-users@stunnel.org>:
Am 25.02.26 um 03:48 schrieb Mike via stunnel-users:
It definitely executes the correct command, but then the whole service shuts down and I get this: Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/ attuverse.conf (code=exited, status=0/SUCCESS)
Off the top of my head: Since you apparently made only minimal changes to the config, chances are that the starting stunnel fork()s, the child puts itself in the background, and the parent exits (proper behaviour for getting fired up by initd). systemd likes to interact with the spawned services (notice when they've terminated abnormally, etc.), so it might expect stunnel *not* to detach itself. "status=0" suggests that stunnel *itself* did *not* see any problem.
I thought the same thing, however, there is no stunnel process running at all.
if I execute this command: /usr/bin/stunnel4 /etc/stunnel/myconffile.conf
(Is that an actual mismatch, or did you just forget to redact the config file's name above ... ?)
Redaction error. :) Thanks.
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
participants (4)
-
Jochen Bern -
Michał Trojnara -
Mike -
Peter Pentchev