Need systemd unit file help.

Lennart Poettering mzerqung at 0pointer.de
Mon Sep 26 16:32:31 UTC 2011


On Sat, 24.09.11 08:48, Richard Shaw (hobbes1069 at gmail.com) wrote:

> I just took over the akmods package at RPM Fusion and one of the many
> BZ requests is to convert it to systemd.
> 
> The current suggestion is:
> [Unit]
> Description=Builds and install new kmods from akmod packages
> After=syslog.target

(Starting with F16 After=syslog.target is not necessary anymore and
should be dropped from unit file. But that's orthogonal to your mail
otherwise.)

> Before=prefdm.service
> 
> [Service]
> Type=oneshot
> ExecStart=-/usr/sbin/akmods --from-init
> 
> [Install]
> WantedBy=multi-user.target
> 
> But this only works for people using the video driver akmod packages.
> There are also other packages such as network drivers and possibly
> others.
>
> Is there some way to make this more dynamic so that the run
> dependencies can be defined by what akmod packages are installed?

Well, you can move your service into the early boot part if
necessary. However, there's a fundamental problem here: iiuc you compile
driver modules at boot and want them recognized by the system during the
same boot run. That's hardly possible though. To compile your modules
you probably need the full set of file systems around (i.e. /var and
/tmp), but that's only available after udev was started and driver
loading triggered. So the earliest time you can build the drivers is
already too late to load them properly.

My question to you: why are these modules built at boot time at all? Why
not at install time? Seems like the more appropriate time to me, given
that the set of kernel packages does not change during boot, but only at
install time.

> I think I remember reading a thread where one unit file can call other
> unit files? Is there some way to setup a akmods.d/ type directory
> where the individual akmod driver packages can stick unit files?

You can do something similar the way Michal suggested.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list