open-iscsi service iscsi-init can run too early, when FS is read-only

[Lee Duncan]

Hi All:

There is an iscsi service that does nothing but create the
initiatorname.iscsi file in /etc/iscsi if it does not yet exist called
iscsi-init.service.

For iscsi boot situations, this service can run quite early, in the
initrd image before the root pivot. Because of this the
DefaultDependencies=no line was added, so it could run earlier. But
because of this change, it can now run too early in the real root. The
problem is that it can actually try to create the initiatorname.iscsi
file before /etc/iscsi is writable! So it generates an error message,
fails to create the initiator name, and it makes the rest of iscsi
services fail, since they depend on iscsi-init.service.

In order to address this, I added this line to the service file:

>
> [Unit]
> ...
> After=root.mount
>

This was an error. I mean to wait for the root disc, not "/root". :( In
testing, this just happened to work on my systems because we use btrfs
by default for the root disc, and btrfs creates a "/root" subvolume
(i.e. mount point).

The mount point target for the root mount is actually called "-.mount".
But even adding this didn't fix my problem with iscsi-init running too
early, and it's because iscsi-init was waiting for the root disc to be
mounted, but it turns out it's mounted read-only for a short time,
before it's remounted read/write. So it was getting an error trying to
create the initiator name file.

Long story shorter, I consulted a systemd expert, and he suggested the
following:

> [Unit]
> # this adds both Requires= and After=
> RequiresMountsFor=/etc/iscsi
> # systemd-remount-fs.service is optionally pulled in by
> # local-fs.target, don't start it here (no Wants=) but if it's
> # running wait for it to finish (After=)
> After=systemd-remount-fs.service

and, to keep iscsi-init.service from running before systemd-remote-fs is
scheduled:

> [Install]
> # just to ensure being in same transaction with
> # systemd-remount-fs.service
> WantedBy=systemd-remount-fs.service

Testing has show this works on several different systems, but before I
"fix" this again, I thought I'd ask for input, in case anyone has
systemd insight I do not.

Suggestions? If I don't hear anything I'll go with the above
recommendations.

If I can't figure this out my next suggestion is going to be doing away
with this service. Once should not ever be in the situation where there
is no initiator name, since that should be generated when the RPM is
installed IMHO (which is what we do).
--
Lee Duncan

[Chris Leech]

I'll give these changes a look, I can never tell what service files
changes are going to do without playing around with them for a bit.

> If I can't figure this out my next suggestion is going to be doing away
> with this service. Once should not ever be in the situation where there
> is no initiator name, since that should be generated when the RPM is
> installed IMHO (which is what we do).

The idea of using a special unit for this came out of issues we had at
Red Hat with generating an initiator name at RPM install time. It
turns out that a lot of systems today aren't installed from RPMs, but
rather users build an image from RPMs and then start up new instances
from that image, especially when virtualized. If image building needs
to remove or replace the initiator name file, it becomes a problem
that deferring to first run time solves.

But if anything I might question the actual value of automatically
generating a random initiator name.

- Chris