Re: [systemd-devel] rpcbind.socket failing

[Lennart Poettering]

On Tue, 01.11.16 20:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 01.11.2016 18:47, Lennart Poettering пишет:
> > On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote:
> > 
> >>
> >>
> >> On 10/31/2016 03:40 PM, Michael Biebl wrote:
> >>> Why is it using /var/run (where /var could be on a separate partition)
> >>> and not /run for the socket files?
> >>
> >> Historical reasons?? I guess that's way its always been
> >> and never caused a problem... 
> > 
> > Yeah, it normally shouldn't create problems – however, you are setting
> > DefaultDependencies=no now, which means you run in early boot, and
> > then things become more complex, as /var is not around fully yet. 
> 
> Unit file had RequiresMountsFor=/var/run. If this is not enough to
> ensure unit starts only after /var/run is mounted, then what exactly
> RequiresMountsFor does?

RequiresMountsFor= orders your unit so that the mount points required
to make the specified path available are mounted first. It thus
guarantees successful read access at the least. If used for regular
services (by which I mean: non-early-boot services) it also gaurantees
successful write access to the directories in question. However,
during early boot things are a bit different: the kernel/initrd might
pre-mount a number of dirs, but generally only in a read-only
mode. Typically the root partition (on which /var is more often than
not located) is read-only this early. Now,
"systemd-remount-fs.service" service is responsible to adjust the
mount flags in a way that they match what /etc/fstab defines.

Hence, to summarize this differently:

1) if you are in late boot and just want to pull in mounts for some
dir and don't want to rely on it being listed as "auto" in fstab, then
use RequiresMountsFor= on it and you are happy

2) if you are in early boot and need read-only access to something,
then use RequiresMountsFor= on it and you are happy

3) if you are in early boot and need write access to something, then
use RequiresMountsFor= in combination with an
After=systemd-remount-fs.service and you should be happy.

Hope this makes sense,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Lennart Poettering]

On Tue, 01.11.16 12:42, Steve Dickson (ste...@redhat.com) wrote:

> 
> 
> On 11/01/2016 12:14 PM, Reindl Harald wrote:
> > 
> > 
> > Am 01.11.2016 um 17:05 schrieb Steve Dickson:
> >> and I still getting the following errors
> >>
> >> rpcbind.socket: Failed to listen on sockets: No such file or directory
> I though this was talking about /run/rpcbind.sock since 
> that's the only patch defined in that file...  I didn't 
> even think it was talking about the patch to the 
> daemon since that's defined in the service file. 
> 
> >> Failed to listen on RPCbind Server Activation Socket.
> >> Starting RPC Bind...
> >> rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No such 
> >> file or directory
> >> rpcbind.service: Main process exited, code=exited, status=203/EXEC
> >> Failed to start RPC Bind.
> Maybe the ENOENT was being carried over to the socket file??

Oh yes, it was. This is because you are using an SELinux-based
distro. And on those the label for the socket is calculated from the
binary that will eventually be started on it. If that binary doesn't
exist, the calculation and the socket binding will fail with ENOENT...

But yeah, we should generate more useful errors in this case, indeed.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Lennart Poettering]

On Wed, 02.11.16 06:16, Kai Krakow (hurikha...@gmail.com) wrote:

> Am Tue, 1 Nov 2016 12:05:43 -0400
> schrieb Steve Dickson :
> 
> > rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No
> > such file or directory
> 
> Do you still use DefaultDependencies=no?
> 
> Then /usr is probably not available that early (now that it can start
> much earlier due to /run being available). What's the exercise of
> disabling default dependencies anyway?

No!

systemd does not support /usr not being around from earliest boot
on. If distros permit /usr being split out onto its own partition they
must pre-mount it in the initrd, so that /usr is constantly available
from the first moment of the host PID 1 to its last moment.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Uoti Urpala]

On Tue, 2016-11-01 at 20:01 +0300, Andrei Borzenkov wrote:
> 01.11.2016 18:47, Lennart Poettering пишет:
> > DefaultDependencies=no now, which means you run in early boot, and
> > then things become more complex, as /var is not around fully yet. 
> > 
> 
> Unit file had RequiresMountsFor=/var/run. If this is not enough to
> ensure unit starts only after /var/run is mounted, then what exactly
> RequiresMountsFor does?

/var/run is not a mountpoint, it's an obsolete compatibility symlink to
/run. Thus that RequiresMountsFor is satisfied as long as /var is
mounted. The symlink is created by tmpfiles. Though even without
correct dependencies on tmpfiles, I'd expect the symlink to already be
around from previous boots on a persistent /var partition, so I don't
know why that'd cause a visible failure.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Uoti Urpala]

On Wed, 2016-11-02 at 06:16 +0100, Kai Krakow wrote:
> Do you still use DefaultDependencies=no?
> 
> Then /usr is probably not available that early (now that it can start
> much earlier due to /run being available). What's the exercise of
> disabling default dependencies anyway?

/usr is always available, it's mounted together with the root fs
(normally by the initramfs if it is a separate partition).

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Kai Krakow]

Am Tue, 1 Nov 2016 12:05:43 -0400
schrieb Steve Dickson :

> rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No
> such file or directory

Do you still use DefaultDependencies=no?

Then /usr is probably not available that early (now that it can start
much earlier due to /run being available). What's the exercise of
disabling default dependencies anyway?

-- 
Regards,
Kai

Replies to list-only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Andrei Borzenkov]

01.11.2016 18:47, Lennart Poettering пишет:
> On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote:
> 
>>
>>
>> On 10/31/2016 03:40 PM, Michael Biebl wrote:
>>> Why is it using /var/run (where /var could be on a separate partition)
>>> and not /run for the socket files?
>>
>> Historical reasons?? I guess that's way its always been
>> and never caused a problem... 
> 
> Yeah, it normally shouldn't create problems – however, you are setting
> DefaultDependencies=no now, which means you run in early boot, and
> then things become more complex, as /var is not around fully yet. 
> 

Unit file had RequiresMountsFor=/var/run. If this is not enough to
ensure unit starts only after /var/run is mounted, then what exactly
RequiresMountsFor does?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Steve Dickson]

On 11/01/2016 12:14 PM, Reindl Harald wrote:
> 
> 
> Am 01.11.2016 um 17:05 schrieb Steve Dickson:
>> and I still getting the following errors
>>
>> rpcbind.socket: Failed to listen on sockets: No such file or directory
I though this was talking about /run/rpcbind.sock since 
that's the only patch defined in that file...  I didn't 
even think it was talking about the patch to the 
daemon since that's defined in the service file. 

>> Failed to listen on RPCbind Server Activation Socket.
>> Starting RPC Bind...
>> rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No such file 
>> or directory
>> rpcbind.service: Main process exited, code=exited, status=203/EXEC
>> Failed to start RPC Bind.
Maybe the ENOENT was being carried over to the socket file??

> 
> come on "No such file or directory" is pretty clear and says your path is 
> just wrong
> 
> [root@rh:~]$ ls /usr/bin/rpcbind
> /usr/bin/ls: cannot access '/usr/bin/rpcbind': No such file or directory
I guess that is where rpcbind lives in SUSE distro... 

> 
> [root@rh:~]$ ls /usr/sbin/rpcbind
> -rwxr-xr-x 1 root root 58K 2016-08-01 19:01 /usr/sbin/rpcbind
Thanks for catch and the time!

steved.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Reindl Harald]

Am 01.11.2016 um 16:11 schrieb Steve Dickson:

On 10/31/2016 03:40 PM, Michael Biebl wrote:

Why is it using /var/run (where /var could be on a separate partition)
and not /run for the socket files?

Historical reasons?? I guess that's way its always been
and never caused a problem...


i strongly doubt that "DefaultDependencies=no" always has been!

>> But the rpcbind.socket does exist
>> # file /var/run/rpcbind.sock
>> /var/run/rpcbind.sock: socket
>>
>> and everything comes up when the daemon is started by hand.
>
> I guess the problem is with the listen directives... See below
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Steve Dickson]

On 11/01/2016 11:47 AM, Lennart Poettering wrote:
> On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote:
> 
>>
>>
>> On 10/31/2016 03:40 PM, Michael Biebl wrote:
>>> Why is it using /var/run (where /var could be on a separate partition)
>>> and not /run for the socket files?
>>
>> Historical reasons?? I guess that's way its always been
>> and never caused a problem... 
> 
> Yeah, it normally shouldn't create problems – however, you are setting
> DefaultDependencies=no now, which means you run in early boot, and
> then things become more complex, as /var is not around fully yet. 
Fair enough... /var is gone so here is the two new sock and server files

rpcbind.socket:

[Unit]
Description=RPCbind Server Activation Socket
DefaultDependencies=no
Wants=rpcbind.target
Before=rpcbind.target

[Socket]
ListenStream=/run/rpcbind.sock

# RPC netconfig can't handle ipv6/ipv4 dual sockets
BindIPv6Only=ipv6-only
ListenStream=0.0.0.0:111
ListenDatagram=0.0.0.0:111
ListenStream=[::]:111
ListenDatagram=[::]:111

[Install]
WantedBy=sockets.target

rpcbind.service:

[Unit]
Description=RPC Bind
Documentation=man:rpcbind(8)
DefaultDependencies=no
# Make sure we use the IP addresses listed for
# rpcbind.socket, no matter how this unit is started.
Wants=rpcbind.socket
After=rpcbind.socket

[Service]
Type=notify
# distro can provide a drop-in adding EnvironmentFile=-/??? if needed.
ExecStart=/usr/bin/rpcbind $RPCBIND_OPTIONS -w -f

[Install]
WantedBy=multi-user.target

and I still getting the following errors

rpcbind.socket: Failed to listen on sockets: No such file or directory
Failed to listen on RPCbind Server Activation Socket.
Starting RPC Bind...
rpcbind.service: Failed at step EXEC spawning /usr/bin/rpcbind: No such file or 
directory
rpcbind.service: Main process exited, code=exited, status=203/EXEC
Failed to start RPC Bind.
SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='unit=rpcbind comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
rpcbind.service: Unit entered failed state.
rpcbind.service: Failed with result 'exit-code'.

Note, I did take out the Bind and Listen lines in the socket
file... to no avail, the same error

Is there some type of debugging I can turn on? Clearly /run/rpcbind.sock
does exist... 

steved
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Lennart Poettering]

On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote:

> 
> 
> On 10/31/2016 03:40 PM, Michael Biebl wrote:
> > Why is it using /var/run (where /var could be on a separate partition)
> > and not /run for the socket files?
>
> Historical reasons?? I guess that's way its always been
> and never caused a problem... 

Yeah, it normally shouldn't create problems – however, you are setting
DefaultDependencies=no now, which means you run in early boot, and
then things become more complex, as /var is not around fully yet. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Steve Dickson]

On 11/01/2016 09:31 AM, Lennart Poettering wrote:
> On Mon, 31.10.16 13:19, Steve Dickson (ste...@redhat.com) wrote:
> 
>> [Unit]
>> Description=RPCbind Server Activation Socket
>> DefaultDependencies=no
>> RequiresMountsFor=/var/run /run
>> Wants=rpcbind.target
>> Before=rpcbind.target
>>
>> [Socket]
>> ListenStream=/var/run/rpcbind.sock
> 
> So you turned off the default dependencies, which means your socket
> unit will be started during earliest boot, at a time where /var is
> usually not writable yet. (You then try to fix this up via the
> RequiresMountsFor= thing, but that will only ensure that /var is
> mounted, it does not require it to actually be writable, or that the
> /var/run → /run symlink was created)
> 
> So, most importantly: please drop all references to /var/run
> here. That's just a legacy alias to /run, implemented via a
> symlink. All distributions, regardless if they adopted systemd or not,
> have switched to making /run a tmpfs and /var/run a symlink to
> it. There's really no point at all in ever referring to /var/run
> again.
Ok... 

> 
> By dropping any reference to /var/run and replacing it by a reference
> directly to /run you make the entire problem set go away: /run is
> guaranteed to always exist on systemd systems, it's always writable,
> and always a tmpfs. PID 1 mounts in in its earliest initialization
> phase, right at the same time it mounts /proc and /sys too.
> 
> Summary:
> 
> a) drop the entire RequiresMountsFor= line, it's useless. /run is
>mounted anyway, and depending on /var/run doesn't do what people
>might think, and you don't need it anway.
> 
> b) Change the ListenStream directive to reference /run/rpcbind.sock
>directly, avoid the indirection via /var/run/rpcbind.sock
The whole point of the exercise is to develop uniformity 
across distros so I'll send post an updates version and
see what is said as well as cc-ing the original author
for comment... 

thanks!

steved.


> 
> Lennart
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Steve Dickson]

On 10/31/2016 06:07 PM, Kai Krakow wrote:
> Am Mon, 31 Oct 2016 13:19:24 -0400
> schrieb Steve Dickson :
> 
>> Upstream has come up with some new rpcbind service socket files
>> and I'm trying to incorporate them into f25.
>>
>> The rpcbind.socket is failing to come up
>>rpcbind.socket: Failed to listen on sockets: No such file or
>> directory Failed to listen on RPCbind Server Activation Socket.
>>
>> But the rpcbind.socket does exist 
>> # file /var/run/rpcbind.sock
>> /var/run/rpcbind.sock: socket
>>
>> and everything comes up when the daemon is started by hand.
> 
> I guess the problem is with the listen directives... See below.
> 
>> old rpcbind.socket file:
>>
>> [Unit]
>> Description=RPCbind Server Activation Socket
>>
>> [Socket]
>> ListenStream=/var/run/rpcbind.sock
> 
> Probably not your problem but it should really point to /run directly
> because /var may not be mounted at that time. Even if /var/run is
> usually a symlink, /var needs to be ready to resolve the symlink. But
> otoh I'm not sure if systemd even supports /var being mounted later and
> not by initramfs.
In the new rpcbind.socket there is a
RequiresMountsFor=/var/run /run so /var should
be there.

> 
>> [Install]
>> WantedBy=sockets.target
>>
>>
>> New rpcbind.socket file:
>>
>> [Unit]
>> Description=RPCbind Server Activation Socket
>> DefaultDependencies=no
>> RequiresMountsFor=/var/run /run
>> Wants=rpcbind.target
>> Before=rpcbind.target
>>
>> [Socket]
>> ListenStream=/var/run/rpcbind.sock
>>
>> # RPC netconfig can't handle ipv6/ipv4 dual sockets
>> BindIPv6Only=ipv6-only
>> ListenStream=0.0.0.0:111
>> ListenDatagram=0.0.0.0:111
>> ListenStream=[::]:111
>> ListenDatagram=[::]:111
> 
> I'm not sure, but I don't think you can combine BindIPv6Only and listen
> on IPv4 sockets at the same time. What if you remove the two ipv4
> style listen directives?
> 
> Maybe remove the complete block if you are going to use only unix
> sockets.
Well I remove the entire block and I still got the failure..

thanks!

steved.

> 
>> [Install]
>> WantedBy=sockets.target
>>
>>
>> ListenStream is the same for both files... 
>> How do I debugging something like this?
>>
>> tia,
>>
>> steved.
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Steve Dickson]

On 10/31/2016 03:40 PM, Michael Biebl wrote:
> Why is it using /var/run (where /var could be on a separate partition)
> and not /run for the socket files?
Historical reasons?? I guess that's way its always been
and never caused a problem... 

steved.

> 
> 2016-10-31 18:19 GMT+01:00 Steve Dickson :
>> Hello,
>>
>> Upstream has come up with some new rpcbind service socket files
>> and I'm trying to incorporate them into f25.
>>
>> The rpcbind.socket is failing to come up
>>rpcbind.socket: Failed to listen on sockets: No such file or directory
>>Failed to listen on RPCbind Server Activation Socket.
>>
>> But the rpcbind.socket does exist
>> # file /var/run/rpcbind.sock
>> /var/run/rpcbind.sock: socket
>>
>> and everything comes up when the daemon is started by hand.
>>
>> old rpcbind.socket file:
>>
>> [Unit]
>> Description=RPCbind Server Activation Socket
>>
>> [Socket]
>> ListenStream=/var/run/rpcbind.sock
>>
>> [Install]
>> WantedBy=sockets.target
>>
>>
>> New rpcbind.socket file:
>>
>> [Unit]
>> Description=RPCbind Server Activation Socket
>> DefaultDependencies=no
>> RequiresMountsFor=/var/run /run
>> Wants=rpcbind.target
>> Before=rpcbind.target
>>
>> [Socket]
>> ListenStream=/var/run/rpcbind.sock
>>
>> # RPC netconfig can't handle ipv6/ipv4 dual sockets
>> BindIPv6Only=ipv6-only
>> ListenStream=0.0.0.0:111
>> ListenDatagram=0.0.0.0:111
>> ListenStream=[::]:111
>> ListenDatagram=[::]:111
>>
>> [Install]
>> WantedBy=sockets.target
>>
>>
>> ListenStream is the same for both files...
>> How do I debugging something like this?
>>
>> tia,
>>
>> steved.
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Lennart Poettering]

On Mon, 31.10.16 13:19, Steve Dickson (ste...@redhat.com) wrote:

> [Unit]
> Description=RPCbind Server Activation Socket
> DefaultDependencies=no
> RequiresMountsFor=/var/run /run
> Wants=rpcbind.target
> Before=rpcbind.target
> 
> [Socket]
> ListenStream=/var/run/rpcbind.sock

So you turned off the default dependencies, which means your socket
unit will be started during earliest boot, at a time where /var is
usually not writable yet. (You then try to fix this up via the
RequiresMountsFor= thing, but that will only ensure that /var is
mounted, it does not require it to actually be writable, or that the
/var/run → /run symlink was created)

So, most importantly: please drop all references to /var/run
here. That's just a legacy alias to /run, implemented via a
symlink. All distributions, regardless if they adopted systemd or not,
have switched to making /run a tmpfs and /var/run a symlink to
it. There's really no point at all in ever referring to /var/run
again.

By dropping any reference to /var/run and replacing it by a reference
directly to /run you make the entire problem set go away: /run is
guaranteed to always exist on systemd systems, it's always writable,
and always a tmpfs. PID 1 mounts in in its earliest initialization
phase, right at the same time it mounts /proc and /sys too.

Summary:

a) drop the entire RequiresMountsFor= line, it's useless. /run is
   mounted anyway, and depending on /var/run doesn't do what people
   might think, and you don't need it anway.

b) Change the ListenStream directive to reference /run/rpcbind.sock
   directly, avoid the indirection via /var/run/rpcbind.sock

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Kai Krakow]

Am Mon, 31 Oct 2016 13:19:24 -0400
schrieb Steve Dickson :

> Upstream has come up with some new rpcbind service socket files
> and I'm trying to incorporate them into f25.
> 
> The rpcbind.socket is failing to come up
>rpcbind.socket: Failed to listen on sockets: No such file or
> directory Failed to listen on RPCbind Server Activation Socket.
> 
> But the rpcbind.socket does exist 
> # file /var/run/rpcbind.sock
> /var/run/rpcbind.sock: socket
> 
> and everything comes up when the daemon is started by hand.

I guess the problem is with the listen directives... See below.

> old rpcbind.socket file:
> 
> [Unit]
> Description=RPCbind Server Activation Socket
> 
> [Socket]
> ListenStream=/var/run/rpcbind.sock

Probably not your problem but it should really point to /run directly
because /var may not be mounted at that time. Even if /var/run is
usually a symlink, /var needs to be ready to resolve the symlink. But
otoh I'm not sure if systemd even supports /var being mounted later and
not by initramfs.

> [Install]
> WantedBy=sockets.target
> 
> 
> New rpcbind.socket file:
> 
> [Unit]
> Description=RPCbind Server Activation Socket
> DefaultDependencies=no
> RequiresMountsFor=/var/run /run
> Wants=rpcbind.target
> Before=rpcbind.target
> 
> [Socket]
> ListenStream=/var/run/rpcbind.sock
> 
> # RPC netconfig can't handle ipv6/ipv4 dual sockets
> BindIPv6Only=ipv6-only
> ListenStream=0.0.0.0:111
> ListenDatagram=0.0.0.0:111
> ListenStream=[::]:111
> ListenDatagram=[::]:111

I'm not sure, but I don't think you can combine BindIPv6Only and listen
on IPv4 sockets at the same time. What if you remove the two ipv4
style listen directives?

Maybe remove the complete block if you are going to use only unix
sockets.

> [Install]
> WantedBy=sockets.target
> 
> 
> ListenStream is the same for both files... 
> How do I debugging something like this?
> 
> tia,
> 
> steved.
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,
Kai

Replies to list-only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rpcbind.socket failing

[Michael Biebl]

Why is it using /var/run (where /var could be on a separate partition)
and not /run for the socket files?

2016-10-31 18:19 GMT+01:00 Steve Dickson :
> Hello,
>
> Upstream has come up with some new rpcbind service socket files
> and I'm trying to incorporate them into f25.
>
> The rpcbind.socket is failing to come up
>rpcbind.socket: Failed to listen on sockets: No such file or directory
>Failed to listen on RPCbind Server Activation Socket.
>
> But the rpcbind.socket does exist
> # file /var/run/rpcbind.sock
> /var/run/rpcbind.sock: socket
>
> and everything comes up when the daemon is started by hand.
>
> old rpcbind.socket file:
>
> [Unit]
> Description=RPCbind Server Activation Socket
>
> [Socket]
> ListenStream=/var/run/rpcbind.sock
>
> [Install]
> WantedBy=sockets.target
>
>
> New rpcbind.socket file:
>
> [Unit]
> Description=RPCbind Server Activation Socket
> DefaultDependencies=no
> RequiresMountsFor=/var/run /run
> Wants=rpcbind.target
> Before=rpcbind.target
>
> [Socket]
> ListenStream=/var/run/rpcbind.sock
>
> # RPC netconfig can't handle ipv6/ipv4 dual sockets
> BindIPv6Only=ipv6-only
> ListenStream=0.0.0.0:111
> ListenDatagram=0.0.0.0:111
> ListenStream=[::]:111
> ListenDatagram=[::]:111
>
> [Install]
> WantedBy=sockets.target
>
>
> ListenStream is the same for both files...
> How do I debugging something like this?
>
> tia,
>
> steved.
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel