On Wed, 14.07.10 08:09, Tomasz Torcz (tomek@xxxxxxxxxxxxxx) wrote:
> On Wed, Jul 14, 2010 at 03:24:06AM +0200, Lennart Poettering wrote:
> > 4) Q: If I don't care about systemd and don't update my packages, will
> > things stop working for me in F14?
> >
> > A: No, they will continue to work. Since systemd's SysV compatiblity is quite
> > extensive things should just continue to work just fine.
>
> I'm maintain a package (hdapsd) which is started on-demand (when hardware appears)
> by upstart. As so, I ship no SysV script, only minimal upstart job description
> activated by hardware addition. In F12 I used to ship a custom udev rule, but
> it became unnecessary with upstart 0.6.
The number of packages currently using Upstart jobs should be very minimal,
which is why I haven't mentioned it in the mail. However, here's how to
cover your case best:
Every device in the udev tree that is tagged with "systemd" appears as
device unit in systemd. Like any other units device units may have
dependencies on any other kind of units, for example service units. For
device units those dependencies may also be configured directly with the
udev rules file.
You would hence write a small udev fragment which does this:
SUBSYSTEM=="block", KERNEL=="sd*", TAG="systemd", ENV{SYSTEMD_WANTS}="hdapsd@%k.service"
(and actually, given that block devices are tagged anyway by a rule we
ship along systemd you could even shorten that and skip the double
tagging. But I left it in above, just to show how it works.)
And then you place as service file hdapsd@.service in
/lib/systemd/system which is then instantiated for each block device,
very much like your current upstart job. See the getty configuration for
an example how to write and use instantiated service files in systemd.
That said, I am a bit puzzled about hdapsd though, since to my knowledge
the kernel does the head parking anyway since kernel 2.6.28 and hence
the package should be obsolete, or isn't it?
> Now, your FAQ only talks about keeping compatibility with SysV
> scripts, which I don't have. There's no mention of compatibility with
> upstart jobs. What should I do? Skip this altogether and move daemon
> startup to new udev rule (like, I believe, blue does)?
No, indeed we do not provide compatibility with upstart jobs.
The bluetooth case we handle a bit differently than what I suggested to
you above: every bluetooth device in the udev tree has a "wants"
dependency on 'bluetooth.target', and 'bluetoothd.service' will then be
pulled in by that. i.e. there is an indirection in place here via the
target unit bluetooth.target, which allows other folks to easily hook in
other stuff into bluetooth by simply placing a dependency from
bluetooth.target onto their service instead of having to write an udev
rule. (and in case you are wondering, in systemd terms 'target units'
are a bit like classic sysvinit runlevels, i.e. can be used to group
multiple services in an easy way, except that you may have multiple
target units actvie, while runlevels you could only have one at a time.)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
