Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Franck Bui]

On 01/25/2018 06:33 PM, Uoti Urpala wrote:
> 
> This would require distinguishing "boot" and "non-boot" modes of
> operation, so that systemd could switch mount handling behavior at some
> point. How would you define where "boot" ends? 

Well "during boot" means mount units pulled in by local-fs.target unit.

Once pulled in by the initial transaction, a mount unit can either:

  1. succeed if the device is already there and mount(8) succeeds
  2. wait for the device appears or a timeout expire
  3. enter in failed state if the timeout expires

This is the defaults and would match the behavior of SysV when it .

The concern here is that PID1 added a new behavior on top of that:

  4. Each time the mount unit is inactive and the device shows up
 automatically start the unit.

And indeed, if the device takes 5 hours to start, this "new" behavior
allows PID1 to mount asynchronously the device regardless of what
happened previously (assuming "nofail" option is used). But at first
glance disabling the timeout seems more appropriate...

Also how apps/users are supposed to access such devices ? should they
wait for systemd to signal that the mount unit is up ? isn't automount
more appropriate in this case ?

Even if some users might find it useful, redefining the meaning of
"auto" option doesn't look correct because as already explained a lot of
users dont expect it and it confuses some applications too.

IMHO introducing it with a brand new option would have been better and
much less confusing. Also this option shouldn't have been specific to
fstab but should have been part of the mount unit option set.

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

Re: [systemd-devel] Question about a random UDP port on rpcbind 0.2.3 started by systemd

[Jérémy Rosen]

if you have the mentionned file (/usr/lib/systemd/system/rpcbind.socket) 
then systemd will open whatever port is described in there and pass it 
pre-opened to rpcbind.


systemd has no idea what that port is for and the file mentionned above 
was provided to systemd by the rpcbind package. You should really ask 
the rpcbind people what it is for, systemd is just the messenger here...


On 26/01/2018 03:48, Bao Nguyen wrote:

Hello evryone,

I would like to ask you a question regarding the new random UDP port in
rpcbind 0.2.3.

In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
rpcbind.service, then I do netstat

udp0  0 0.0.0.0:111 0.0.0.0:*
  10408/rpcbind
udp0  0 0.0.0.0:831 0.0.0.0:*
  10408/rpcbind
udp6   0  0 :::111  :::*
 10408/rpcbind
udp6   0  0 :::831  :::*
 10408/rpcbind

The rpcbind does not only listen on port 111 but also on a random udp port
"831" in this case, this port is changed every time the rpcbind service
retstarts. And it listens on 0.0.0.0 so it opens a hole on security.

I have looked into the change of rpcbind 0.2.3 and found the change "
rpcbind: add support for systemd socket activation", it calls a
function sd_listen_fds, I do not know much about systemd socket activation
programming, does the "831" port is generated from rpcbind to communicate
with systemd socket activation?

Could you please let me know what this port is for and is there any way to
avoid that like force it listen on a internal interface rather than on any
interfaces like that? As the rpcbind is started from systemd so "-h" option
is invalid as the man page says:


-h  Specify specific IP addresses to bind to for UDP requests.  This
option may be specified multiple times and can be used to restrict the
interfaces rpcbind will respond to.  Note that when rpcbind is controlled
via sys-
  temd's socket activation, the -h option is ignored. In this
case, you need to edit the ListenStream and ListenDgram definitions in
/usr/lib/systemd/system/rpcbind.socket instead.



Thanks a lot,
Brs,
Bao



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


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel