On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: > On 27 July 2015 at 12:36, Lennart Poettering <lenn...@poettering.net> wrote: > > On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
