systemd-udev-settle.service is deprecated. Please fix zfs-import-cache.service not to pull it in.

[mabod]

System information

Type	Version/Name
Distribution Name	Manjaro
Distribution Version	Testing
Linux Kernel	5.4, 5.8
Architecture	amd64
ZFS Version	0.8.4
SPL Version	0.8.4

Describe the problem you're observing

During every boot I get the following message:

udevadm[398]: systemd-udev-settle.service is deprecated. Please fix zfs-import-cache.service not to pull it in.

And this is true since July, not just recently. Nevertheless, the pools are imported just fine. But from my point of view that needs to be fixed.

[PrivatePuffin]

"And this is true since July, not just recently."

• Thats pretty recent in regards to the OpenZFS release timetable, last release was from May.
  It does still needs to be fixed however!

[mabod]

July is where my log starts. I do not have anything earlier than that. The message may have started to occur earlier than that.

[PrivatePuffin]

@mabod Thanks, thats quite relevant to note... It now sounds like it only appears since July... ;)

[mabod]

I checked my backup. I see the messages in the oldest backup I have from 27. April:

Apr 27 09:00:25 rakete udevadm[448]: systemd-udev-settle.service is deprecated.

By the way, the more detailed message which explicitly names zfs-import-cache.service started with 7. August.

[behlendorf]

cc: @aerusso @InsanePrawn @rlaager

[rlaager]

This is likely going to be non-trivial to fix without creating race condition boot failures. We really need the full proper solution of incremental assembly. That is, as ZFS devices appear, build up pool/vdev information in memory. Once there are sufficient disks to import the pool, (if not all disks are present) start a timer. At the earlier of all the disks appearing or the timer elapsing, import the pool. This would probably be in zed but could be in the kernel.

The mount generator should make filesystem mount units depend on some unit for the pool, which in some way only gets started once the pool has imported.

Edit: A way to make this work without all that effort might be to have the generator build a unit to import a specific pool and have that unit depend on the underlying devices. The concern I have with that is that it would presumably fail if a device is missing, defeating the pool redundancy.

[aerusso]

#4943 I think would have addressed this, and it touched on many of your point, @rlaager.

This is what I'm imagining:

1. zfs-pool-member@.service files that wait for /dev/%i to be ready, with some timeout.
2. zfs-pool@.service that Requires= and Before= those member service files, and performs a pool import
3. Code that lets us tell zpool import what specific devices to use, and not scan everything---not strictly necessary, but would be really great for a bunch of reasons.
4. zfs-mount-generator to make the mount units depend on the zfs-pool@.service
5. history_event-zfs-list-cacher.sh to keep zfs-pool-member@ symlinks appropriately updated.

[rlaager]

That should work. It's slightly different than what I proposed, but likely far less work since it leverages systemd. The main difference is that I was proposing a relative timeout (once enough devices are present, start the timeout) and this would use an absolute timeout (start the timer for all disks initially). That's not likely a big difference in practice.

[rnhmjoj]

"And this is true since July, not just recently."

Thats pretty recent in regards to the OpenZFS release timetable, last release was from May.
It does still needs to be fixed however!

The messages started to name "offending" units this summer, but the use of systemd-udev-settle.service has been discouraged since 2011 and deprecated since ~2018.

Future versions of systemd will print this message on boot:

Usage of the systemd service unit systemd-udev-settle.service is deprecated. It
inserts artificial delays into the boot process without providing the
guarantees other subsystems traditionally assumed it provides. Relying on this
service is racy, and it is generally a bug to make use of it and depend on it.

Traditionally, this service's job was to wait until all devices a system
possesses have been fully probed and initialized, delaying boot until this
phase is completed. However, today's systems and hardware generally don't work
this way anymore, hardware today may show up any time and take any time to be
probed and initialized. Thus, in the general case, it's no longer possible to
correctly delay boot until "all devices" have been processed, as it is not
clear what "all devices" means and when they have been found. This is in
particular the case if USB hardware or network-attached hardware is used.

Modern software that requires some specific hardware (such as a network device
or block device) to operate should only wait for the specific devices it needs
to show up, and otherwise operate asynchronously initializing devices as they
appear during boot and during runtime without delaying the boot process.

It is a defect of the software in question if it doesn't work this way, and
still pulls systemd-udev-settle.service into the boot process.

Please file a bug report against the following units, with a request for it to
be updated to operate in a hotplug fashion without depending on
systemd-udev-settle.service: