From: Peter Rajnoha <prajnoha@redhat.com>
To: lvm-devel@redhat.com
Subject: master - systemd: depend on systemd-udev-settle unit in activation unit
Date: Thu, 13 Sep 2012 11:05:50 +0200 [thread overview]
Message-ID: <5051A1EE.2040309@redhat.com> (raw)
In-Reply-To: <20120912151945.GC3870@nostromo.devel.redhat.com>
On 09/12/2012 05:19 PM, Bill Nottingham wrote:
>> The thing with scsi_wait_scan was only added in the way as
>> an addendum to udev-settle functionality (as the next unit
>> that is executed just after udev-settle).
>>
>> If scsi_wait_scan stayed, then we'd better ask systemd
>> upstream to include the unit with scsi_wait_scan there
>> as an official unit distributed with systemd (but I think
>> they counted with its removal so they did not bother to
>> include it anymore). I haven't inspected where other
>> distros called this scsi_wait_scan in their bootup process,
>> if it was called at all there.
>>
>> As for Fedora, F17 still uses fedora-wait-storage unit
>> (having the modprobe scsi_wait_scan call), F18 and higher
>> still has this unit, but it's failing as the module is not
>> available anymore (the unit will be be removed soon I guess).
>>
>> I think that for upstream solution, it's far better to depend
>> on systemd-udev-settle.service. If there's anything else to
>> wait for besides udev, it should be included in systemd upstream
>> as an official and extra unit (so other distros would take that
>> from systemd upstream when packaging).
>
> Without scsi-wait-scan, I'm not sure that depending on udev-settle
> will actually gain you much here - udev will have settled while
> background scsi scans are still happening.
>
Yes, you're right... for older systems where this module is still
present, we should still use the scsi-wait-scan.
However, this is now (at least in Fedora) maintained under
our own initscripts which is not present in all distros I guess.
I'm just trying to point out that it would be better to have
this "fedora-storage-wait" unit in systemd/udev upstream directly
and give it a common name like "storage-wait" which other
storage-related upstream projects could use for reference in
their systemd units if we want to keep it for backward compatibility.
But since the module is now gone, I'm inclined to using systemd-udev-settle
instead and if an update/rebase is needed in packages in older
distro releases, just providing a simple one line patch attached
directly to the build (making use of the original fedora-storage-wait.service).
BTW, just curious, shouldn't we call udev-settle even after
modprobe scsi_wait_scan as well?
Peter
next prev parent reply other threads:[~2012-09-13 9:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 9:37 master - systemd: depend on systemd-udev-settle unit in activation unit Peter Rajnoha
2012-09-12 11:11 ` Zdenek Kabelac
2012-09-12 11:35 ` Peter Rajnoha
2012-09-12 15:19 ` Bill Nottingham
2012-09-13 9:05 ` Peter Rajnoha [this message]
2012-09-13 18:12 ` Bill Nottingham
2012-09-14 7:14 ` Peter Rajnoha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5051A1EE.2040309@redhat.com \
--to=prajnoha@redhat.com \
--cc=lvm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.