[systemd-devel] fstab generator and nfs-client.target

Lennart Poettering lennart at poettering.net
Mon Jul 27 11:58:14 PDT 2015


On Mon, 27.07.15 15:37, Felipe Sateler (fsateler at debian.org) wrote:

> On 27 July 2015 at 12:36, Lennart Poettering <lennart at poettering.net> wrote:
> > On Mon, 27.07.15 15:19, Felipe Sateler (fsateler at debian.org) wrote:
> >
> >> On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote:
> >>
> >> > Coming back to your original question, there are two options:
> >> >
> >> > 1) nfs-common becomes a normal multi-user.target service, but adds
> >> >    Before=remote-fs-pre.target. This way, the service is started at
> >> >    boot, and not only on first use.
> >>
> >> This would have the side effect of nfs-common not being started in single
> >> user mode, which is not likely to be the wanted outcome.
> >
> > Well, then set DEfaultDEpendencies=no and pull it in by
> > sysinit.target. But that's only OK if the service is capable of
> > running in early-boot mode (i.e does not try to access /var and stuff).
> 
> Or basic.target? The description of basic.target says:
> 
> >> Usually this should pull-in all mount points, swap devices, sockets, timers,
> >> and path units and other basic initialization necessary for general purpose
> >> daemons.
> 
> Something that provides services for mountpoints could be hooked up here, no?
> 
> The description of sysinit.target doesn't really tell me what this
> target is all about, or how to choose between it and basic.target.

Yeah, it's not obvious. Basically, sysinit.target is where all the
small early-boot mini-services are pulled in. basic.target otoh pulls
in the various other targets then, without pulling in any .mount,
.service, .socket, ... units on its own.

Or in other words: we group all early-boot services in sysinit.target,
we group all mounts in local-fs.target, all swaps in swaps.target, all
sockets in sockets.target, and so on, and then group all the
aforementioned targets as basic.target. Makes sense?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list