I noticed this today after the systemd update and after I rebooted - stunnel package fails to create /run/stunnel and so stunnel.service won't start as it cannot chroot to /var/run/stunnel.
stunnel was updated for me on 10/21 from 5.03 to 5.06. Machine has been rebooted since then - so it -seems- like a change happened in systemd which triggered this, but I'm not sure.
Work around is to add these 2 lines to /etc/systemd/system/stunnel.conf before the ExecStart line:
ExecStartPre=-/usr/bin/mkdir /run/stunnel ExecStartPre=/usr/bin/chown -R stunnel:stunnel /run/stunnel
Probably just a minor package bug.
gene
On Wed, Oct 29, 2014 at 8:08 PM, Genes Lists lists@sapience.com wrote:
Work around is to add these 2 lines to /etc/systemd/system/stunnel.conf before the ExecStart line:
ExecStartPre=-/usr/bin/mkdir /run/stunnel ExecStartPre=/usr/bin/chown -R stunnel:stunnel /run/stunnel
Shouldn't that rather be handled by a tmpfiles.d snippet, and not in the service file?
Regards, ~Celti
On Wed, 29 Oct 2014 20:17:19 -0700 "Patrick Burroughs (Celti)" celticmadman@gmail.com wrote:
On Wed, Oct 29, 2014 at 8:08 PM, Genes Lists lists@sapience.com wrote:
Work around is to add these 2 lines to /etc/systemd/system/stunnel.conf before the ExecStart line:
ExecStartPre=-/usr/bin/mkdir /run/stunnel ExecStartPre=/usr/bin/chown -R stunnel:stunnel /run/stunnel
Shouldn't that rather be handled by a tmpfiles.d snippet, and not in the service file?
Regards, ~Celti
Yes, tmpfiles is the correct way of handling this and there is already a conf file installed by stunnel that should be creating this dir. If it's not, the OP needs to look into why.
On 10/30/2014 02:08 AM, Doug Newgard wrote:
On Wed, 29 Oct 2014 20:17:19 -0700 "Patrick Burroughs (Celti)" celticmadman@gmail.com wrote: ...
Shouldn't that rather be handled by a tmpfiles.d snippet, and not in the service file?
..
Yes, tmpfiles is the correct way of handling this and there is already a conf file installed by stunnel that should be creating this dir. If it's not, the OP needs to look into why.
1) This has been working fine till yesterday after systemd update to 217-1. I use it every day.
2) There is a tmpfiles snippet:
# cat /usr/lib/tmpfiles.d/stunnel.conf d /var/run/stunnel 0770 stunnel stunnel -
3) So the question now is why was /run/stunnel not created at boot?
journal only has this reference to tmpfiles:
...systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start ..setup.service/start deleted to break ordering cycle starting with basic.target/start
What else can I look for that would help track down the issue?
Thanks. gene
Genes Lists lists@sapience.com on Thu, 2014/10/30 08:23:
- There is a tmpfiles snippet:
# cat /usr/lib/tmpfiles.d/stunnel.conf d /var/run/stunnel 0770 stunnel stunnel -
- So the question now is why was /run/stunnel not created at boot?
journal only has this reference to tmpfiles:
Did not check, but...
Possibly /var/run is no longer linked to ../run? You should change the path in /usr/lib/tmpfiles.d/stunnel.conf from "/var/run/stunnel" to "/run/stunnel".
On 10/30/2014 08:27 AM, Christian Hesse wrote:
Possibly /var/run is no longer linked to ../run? You should change the path in /usr/lib/tmpfiles.d/stunnel.conf from "/var/run/stunnel" to "/run/stunnel".
I did check that and /var/run is indeed linked to /run.
Genes Lists lists@sapience.com on Thu, 2014/10/30 08:52:
On 10/30/2014 08:27 AM, Christian Hesse wrote:
Possibly /var/run is no longer linked to ../run? You should change the path in /usr/lib/tmpfiles.d/stunnel.conf from "/var/run/stunnel" to "/run/stunnel".
I did check that and /var/run is indeed linked to /run.
Or it creates /var/run/stunnel, then removes /var/run to link it against ../run? I would suggest to fix pathes, then try again.
Hi there,
tmpfiles.d is not the right approch: There is the RuntimeDirectory keyword for unit files to manage that directory. See http://www.freedesktop.org/software/systemd/man/systemd.exec.html for details.
The advantage of this keyword is that systemd makes sure that it is pristine whenever the service is started.
Maybe your stunnel unit is already using this? That would explain why the directory is gone (when the service is not running at least).
Best Regards, Tobias
On Thu, Oct 30, 2014 at 2:24 PM, Christian Hesse list@eworm.de wrote:
Genes Lists lists@sapience.com on Thu, 2014/10/30 08:52:
On 10/30/2014 08:27 AM, Christian Hesse wrote:
Possibly /var/run is no longer linked to ../run? You should change the path in /usr/lib/tmpfiles.d/stunnel.conf from "/var/run/stunnel" to "/run/stunnel".
I did check that and /var/run is indeed linked to /run.
Or it creates /var/run/stunnel, then removes /var/run to link it against ../run? I would suggest to fix pathes, then try again. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On 10/30/2014 12:04 PM, Tobias Hunger wrote:
Hi there,
tmpfiles.d is not the right approch: There is the RuntimeDirectory keyword for unit files to manage that directory. See http://www.freedesktop.org/software/systemd/man/systemd.exec.html for details.
The advantage of this keyword is that systemd makes sure that it is pristine whenever the service is started.
Maybe your stunnel unit is already using this? That would explain why the directory is gone (when the service is not running at least).
Hi
The stunnel package from community does not include that variable nor does it include the user,group which would be necessary as well I would think.
I'm still perplexed what systemd 217 did to trigger this being an issue now.
Anyway here's what I see:
$ cat /usr/lib/systemd/system/stunnel.service [Unit] Description=SSL tunnel for network daemons After=syslog.target
[Service] ExecStart=/usr/bin/stunnel Type=forking
[Install]
Other services are also failing with missing /run directories - this is not limited to stunnel it seems.
I notice that php-fpm.service is also failing the same way - there may be others.
For what it's worth - systemd 217-3 does not fix the issue.
I suspect there may be other services which are failing due to missing /run/<foo> as well.
gene/
arch-general@lists.archlinux.org