Am Mittwoch, den 21.08.2019, 09:32 +0100 schrieb Colin Hogben: > On 20/08/19 16:54, Silvio Knizek wrote: > > > The NFS root needs to be mounted in the initrd step. Else > > everything will break. With systemd in the initrd you gain the > > possibilty to depend on those units in the actual system. > > Booting with an NFS root is working fine. I'm not sure how to tell > whether or not I have "systemd in the initrd" as you describe; I > built the initrd with dracut, and I get the > random: systemd-udevd: uninitialized urandom read (16 bytes read) > messages before > dracut: Mounted root filesystem ... Ah, than it should be fine. dracut actually does it right® > > > Why not systemd-networkd, > > systemd-networkd is inadequate for the task. Even though I could > potentially parse the ntp servers out of the lease file (is that even > a public interface with stable format?), I didn't find a way, > documented or undocumented, for getting the log-server. Indeed, from > scanning the source code it seems that any DHCP options other than > some core ones and those in the private range, e.g. 7 (log-server), > are just ignored. (Bizarrely, systemd-networkd does include a DHCP > server - WTF?! DOTADIW? But I digress...) sd-networkd would tell sd-timesyncd by themself. But yeah, currently you can't add random options to the dhcp client. > > > systemd-journald with remote-forwarding > > enabled > > I didn't know it could do that. Googling e.g. > https://unix.stackexchange.com/questions/394822 and the linked > Redhat recommendation suggest otherwise. I found references to > systemd-journal-netlogd (WIP? PR #1890 rejected), and some other > systemd stuff which didn't support traditional UDP output. sd-journald would use it's own transport via HTTP(S). See man:systemd- journal-gatewayd, man:systemd-journal-upload and man:systemd-journal- remote There are also other tools to directly read from the journal and into the appropriate backend for elasticsearch, graylog and other. > > > and systemd-timesyncd? > > Only because it isn't (wasn't) packaged for CentOS 7. In fact I used > it in another project and I'd forgotten I even found a way to > integrate it with dhclient: > https://www.raspberrypi.org/forums/viewtopic.php?t=217832 If you're stuck with dhclient and old versions of systemd, than use ntpd or ntpdate, no problem. > > > > > moreover you want daemon.service to be part of the startup > > > > transaction (I'm not certain why) > > > > > > Well, I'm not sure why I wouldn't. The whole purpose of the > > > system is to run that service. > > But the trigger for the .service is not start up, but accessibilty > > and if certain information are available. > > Other network-facing services e.g. sshd have WantedBy=multi- > user.target - I don't see how my service is in principle > different. I just has some extra dependencies. sshd.service is totaly fine by starting without network. It sounds like your service needs a network and information from dhclient to be up probably. > > > > Having to write looping shell-scripts or reinvent inotifywait > > > seems contrary to the spirit of systemd, but maybe I have to do > > > that. > > You don't have to reinvent the wheel. You just need to know about > > the capabilities of systemd. > > I'm trying to learn. How can I get a systemd unit to defer its > start until certain information is available from dhclient? Well, in dhclient you can define a script which is executed as soon as there is a lease. Use this to trigger further units as this is your trigger. See man:dhclient-script The normal start up logic is not appliable here. You want dhclient as trigger after writing config files.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
