Comment 13 for bug 453365

On 12/09/2009 02:54 PM, Anders Kaseorg wrote:
> Even if it is desirable to convert openafs-client to upstart right now,
> forcing dkms to load after rc would force openafs-client to load after
> rc. This will be a problem for other services that depend on openafs,
> such as apache2 installations with docroot in /afs.
>
> dkms provides kernel modules, and userspace services always depends on
> kernel modules being available, never the other way around, so delaying
> dkms toward the very end of the boot process seems strange anyway.
>
> In short, I see many advantages to loading dkms before legacy SysV
> services, and no advantages to loading it after. The upstart transition
> can happen either way. Is there something I missed?
>
> Perhaps we should try to get feedback from an Upstart developer?
>
>
Regardless of the outcome of the rules to when DKMS starts, I'd argue
that this type of problem is begging for the broken pieces to each be
converted to upstart anyway. Openafs should be satisfying a network
filesystems need, and these other services such as apache shouldn't be
starting until the network file systems are ready.

Now, if you chain that with the openafs upstart job waiting for DKMS to
be done and apache/mysql/$favorite_server_service waiting for network
file systems to be ready and you've got a very logical ordering to your
boot process.

I'll have to see how this setup behaves if DKMS loads before the legacy
SysV services, particularly since that might trigger things rather than
gdm as originally intended for the desktop case.

--
Mario Limonciello
<email address hidden>