Hi Felipe, On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote: > > It is plenty usable, just not if you are using systemd. Yes, I am aware > > policy at this point requires systemd support. > > OK, sorry. The impression I had from your earlier message is that it > didn't work[1].
Ahh, I see. No, the package provides the utilities necessary to mount FCoE volumes, it just does not work when you try to mount them automatically at boot time. I would be curious how systemd accomplishes the necessary ordering if that is working with the systemd units. If so, when I have some time I will have to try and understand what systemd is doing. As far as I can tell this problem is not well solved, at least in sysvinit. NFS has a special arrangement. FCoE and iSCSI can't work as far as I can tell because the network must come up in order to discover volumes, but aside from NFS, volumes are mounted before the network is brought up. If Debian has a provision to mark f.e. an ext4 volume as a network volume in /etc/fstab, I do not know about it. Additionally, in sysvinit the network is stopped before unmounting volumes, so when the system attempts to unmount the FCoE volumes, the network is already down and the system waits forever for the volumes to unmount. Both of these problems can be worked around with kludgy init hacks that are not really a high enough quality to ship in Debian. Resolving these problems the right way is what I was referring to when I said the init scripts need work. > 0030-fcoe.service-Add-foreground-to-prevent-fcoemon-to-be.patch > > => Seems to me it is better to change the unit to Type=forking > instead? This way, systemd would know when the monitor is ready. Given the description of Type=forking that does sound sensible. > debian/rules: > > => it seems weird to me that the socket is not started by default. Maybe something to do with the hack-y version of dealing with forking? Thanks, -Jacob
