OP's only concern appears to be "have a nice day". I was going to do that.
cheers!
mar77i
On Sat, 12 Mar 2016 18:53:42 + (GMT), flow wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>* stunnel.service - SSL tunnel for network daemons
> Loaded: loaded (/usr/lib/systemd/system/stunnel.service; enabled;
> vendor preset: disabled) Active: failed (Result: exit-code)
> Process:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* stunnel.service - SSL tunnel for network daemons
Loaded: loaded (/usr/lib/systemd/system/stunnel.service; enabled; vendor
preset: disabled)
Active: failed (Result: exit-code)
Process: 583 ExecStart=/usr/bin/stunnel (code=exited, status=1/FAI
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
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 sys
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 th
Genes Lists 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
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 on Thu, 2014/10/30 08:23:
>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:
Did not
On 10/30/2014 02:08 AM, Doug Newgard wrote:
On Wed, 29 Oct 2014 20:17:19 -0700
"Patrick Burroughs (Celti)" 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
On Wed, 29 Oct 2014 20:17:19 -0700
"Patrick Burroughs (Celti)" wrote:
> On Wed, Oct 29, 2014 at 8:08 PM, Genes Lists
> 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
> > ExecStart
On Wed, Oct 29, 2014 at 8:08 PM, Genes Lists 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
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 -see
13 matches
Mail list logo
