[PKG-Openstack-devel] Bug#858533: rtslib-fb-targetctl: doesn't work with sysvinit due to missing configfs mount

[Christian Seiler]

On 03/29/2017 03:31 PM, Harald Dunkel wrote:
> I agree about mounting configfs in the init script, but please
> note that /sys/kernel/config *is* mounted early at boot time.
> Its just not available yet.

No, it isn't mounted early at boot time, at least not from
sysvinit, due to a bug (see below).

> Maybe the LSB header is bad, or the timeout in rtslib-fb-targetctl
> has to be increased.

So apparently something else mounts configfs in your case that
is run in parallel to LIO. But the LSB headers of targetctl
clearly indicate that it's a standard service that's run _way_
later than early-boot services, even after $remote_fs - so
/etc/init.d/mountkernfs.sh will definitely have been run already
at that point.

The problem with mountkernfs.sh in sysvinit is that it will only
mount configfs if /sys/kernel/config exists, which will only
exist if the configfs module is loaded, which will only happen
after mountkernfs.sh is started on sysvinit. (systemd in contrast
loads modules before mounting things such as configfs nowadays;
it also got that wrong in the past though.) This bug in sysvinit
(or more accurately the initscripts package) is the bug I
referenced:

https://bugs.debian.org/840356

If in your case after boot configfs is mounted anyway, there's
another service that does that for you. Could you grep for
configfs in /etc/init.d? You'll probably fine something other
than targetctl or mountkernfs.sh that will mount it at a later
point in boot - but that's definitely not something I'd rely
on.

The proper way to fix this is to fix the initscripts package to
load modules before mounting configfs. Since targetctl is not
an early-boot service, ordering will automatically be correct
then and your use case will work.

However, that's something you'll have to take up with the
sysvinit/initscripts maintainers, because it clearly is a bug
in those packages.

(Actually, this is the first time I've looked at the targetctl
init script, and the loop in there waiting for configfs to be
mounted really should NOT be there, that is just plain wrong.
configfs availability should be done via ordering, not waiting
in the packground for stuff to start - because that really is
non-deterministic. And the ordering is actually correct
already; the other package that mounts configfs in the init
script is buggy in my eyes because it does something it should
not, as well as sysvinit for not properly mounting configfs in
the first place.)

The only "workaround" would be to mount configfs ourselves in
the targetctl init script, but to me this really not
advisable, because if something else is already mounting
configfs in the background, then the mount command could be
issued twice - which shouldn't happen, and can cause some
unexpected issues (appearing in /proc/mounts or
/proc/self/mountinfo twice for the same mount point could break
some scripts that don't expect that, for example. And since
the mount command being issued twice depends on a race
condition, this would be non-deterministic and very difficult
to debug).

Regards,
Christian