[systemd-devel] [RFC] iscsid / systemd / dracut integration effort
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Tue Dec 11 16:46:06 PST 2012
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
More information about the systemd-devel
mailing list