[Pkg-fcoe-general] Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file

[Sylvain Costard]

Hello,

I'll try to explain how works fcoe-utils.

Fcoemon is an utility that checks for incoming devices the ability to 
handle fcoe. If an interface (configured in /etc/network/intefarces 
*AND* in /etc/fcoe/) comes up with this ability then the fcoemon will 
create fc_host block devices.

The original package had no systemd ability and the sysVinit system was 
buggy. Has Stretch tends to be systemd alike we configured it to handle it

This deb package has been tested (reboot/start/stop/install/uninstall) 
under our infrastructure and works with this following Hardware :

BL465c Gen8 with HP VC FlexFabric-20/40 F8 Module (embeddeb with QLogic 
QMH2572 8Gb FC HBA for HP BladeSystem c-Class) in a HP C7000 Enclosure

On related link : https://www.kernel.org/doc/Documentation/scsi/bnx2fc.txt

Regards,

-- 
  🐧 M. Sylvain COSTARD
  🎓 Université Rennes 2
      Direction du Système d'Information
       Pôle Infrastructure / Serveurs
  🔗http://www.univ-rennes2.fr/dsi




Le 25/01/2017 à 22:43, Jacob Luna Lundberg a écrit :
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-fcoe-general/attachments/20170126/5c47a28a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3649 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.alioth.debian.org/pipermail/pkg-fcoe-general/attachments/20170126/5c47a28a/attachment-0001.bin>