[systemd-devel] Managing autogenerated services

[Mike Kazantsev]

On Wed, 1 Jun 2011 21:21:35 +0200
yoshi watanabe <yoshi314 at gmail.com> wrote:

> systemd would not order my lvm based mounts after lvm service. i had
> to rewrite mounts by writing manual services for them, that would do
> ExecStart=mount (...) and ExecStop=umount (...)
> with after=lvm.service or similar.
> 
> i seem to have a really oddball partition setup, as it's being very
> troublesome for systemd.
> 

I've always used systemd with lvm-based partitions as well (usually on
top of dm-crypt), nothing particulary odd there.

*.device units (which *.mount depend on) in systemd will wait for
devices to appear for quite a while, so if lvm started in parallel with
mount units, it shouldn't be a problem.

So I'd make sure that LVM starts at all before .device units time out
first. And if systemd still unable to see devices after that, it can be
related to udev/lvm versions or initrd (and udev or it's rules there).


> might be worth posting in another thread.
> 
> 2011/6/1 Mike Kazantsev <mk.fraggod at gmail.com>:
> > On Wed, 1 Jun 2011 15:36:55 +0200
> > yoshi watanabe <yoshi314 at gmail.com> wrote:
> >
> >> Hi all
> >>
> >> I'd like to know how can one manage services that are being auto
> >> generated (e.g. mount points or cryptsetup).
> >>
> >> In case of mount points, i would like to have all mount services
> >> depend on arbitrary service of my choice. How do i do that?
> >>
> >
> > A bit of a hack and probably depends on what you mean by "depend on
> > arbitrary service", but since all mount units have "Requires=-.mount"
> > and "After=-.mount", you should be able to create that unit manually
> > (overriding auto-generated one) and add any ordering or requirements
> > there.
> >

-- 
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110602/35b7a3b3/attachment.pgp>