On Thu, Feb 17, 2022 at 10:42 AM 'Lee Duncan' via open-iscsi <[email protected]> wrote: > > 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.
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 -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAPnfmXKkPsmzax38_tgBQV2vURso1e9MwYiL74rV1%3DvH8OZxtA%40mail.gmail.com.
