Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort

["\"Jóhann B. Guðmundsson\"" <johannbg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 12/11/2012 11:26 PM, Chris Leech wrote:
> On Mon, Dec 10, 2012 at 11:56:07PM +0000, "Jóhann B. Gušmundsson" wrote:
>> On 12/10/2012 10:08 PM, Chris Leech wrote:
>>> 2) Proper ordering of the iscsi.service for non-root filesystems.
>>>
>>> Any and all feedback and/or help welcome.
>>>
>> Looking the unit file for iscsid I do believe I missed this (
>> basically the same as multipath unit ) since you know it's early
>> boot special, root and all that ;)
>>
>> [Unit]
>>
>> # Before or After lvm2-activation-early.service
>> DefaultDependencies=no
>> Conflicts=shutdown.target
>>
>> [Install]
>> WantedBy=sysinit.target
> Thanks, this got me going in the right direction.  These unit files
> seems to be working much better for me, with the startup and shutdown
> ordering between iscsi, iscsid, and remote-fs mounts sorted out.  I'm
> not sure about the tgtd/targetcli stuff, not sure what the original need
> there was.

You should remove if it's not necessary for iscsi to function and the 
ordering for iscsi be put in those units instead

>
> My non-root test install with /home on iSCSI also has a swap partition
> on it, and that's still causing me all sorts of trouble if I don't
> comment it out in fstab.

Hmm even if you add noauto after the relevant swap entry in /etc/fstab 
actually it might be necessary for you to create a .swap unit for it.
( man systemd.swap for details )

>    Trying to order all this before swap.target
> blew up in my face pretty good.

You should not order it after the swap.target however you can order 
.swap unit before the swap.target

>
> - Chris
>
> --- iscsi.service ---
>
> [Unit]
> Description=Login and scanning of iSCSI devices
> Documentation=man:iscsiadm(8) man:iscsid(8)
> DefaultDependencies=no
> Conflicts=shutdown.target
> After=systemd-remount-fs.service network.target iscsid.service iscsiuio.service
> Before=remote-fs.target
> ConditionPathExists=/etc/iscsi/initiatorname.iscsi
>
> [Service]
> Type=oneshot
> ExecStart=/usr/libexec/iscsi_mark_root_nodes
> ExecStart=/sbin/iscsiadm -m node --loginall=automatic
> ExecStop=/bin/sync
> ExecStop=/sbin/iscsiadm -m node --logoutall=automatic
> RemainAfterExit=true
>
> [Install]
> WantedBy=sysinit.target
>
> --- iscsid.service ---
>
> [Unit]
> Description=Open-iSCSI
> Documentation=man:iscsid(8) man:iscsiadm(8)
> DefaultDependencies=no
> Conflicts=shutdown.target
> After=network.target tgtd.service targetcli.service
> Before=remote-fs-pre.target
>
> [Service]
> Type=simple
> ExecStart=/usr/sbin/iscsid -f -n
> ExecStop=/sbin/iscsiadm -k 0 2
>
> --- iscsid.socket ---
>
> [Unit]
> Description=Open-iSCSI iscsid Socket
> Documentation=man:iscsid(8) man:iscsiadm(8)
>
> [Socket]
> ListenStream=@ISCSIADM_ABSTRACT_NAMESPACE
>
> [Install]
> WantedBy=sockets.target
>
>

So it seems to be in ready enough to be pushed to rawhide and the next 
step is to boot with "systemd.log_level=debug systemd.log_target=kmsg 
log_buf_len=1M enforcing=0" in the kernel command line to actually see 
why that's blowing up in your face.

One question the iscsid is calling fork() right so why are you so 
incline to use type simple for it?

There is an ordering gotcha when using type simple units which boils to 
systemd has no way of knowing if what it just fired up is finished 
running/setup etc. ( unless notified ) so you might find yourself in a 
race condition.

JBG

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to open-iscsi+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.