Re: [systemd-devel] Deferring start of service until file exists
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 ... 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...) 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. 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 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. 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? -- Colin Hogben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timedated: Not possible to set time zone that is a symlink!
Hi, Sorry, for this late reply, vacation and other priorities. > > I am asking because our system mount /usr/share/zoneinfo as > > read-only and because of legacy we need to support the user being > > able to change the TZ string in a tz-file. Installing a symlink that > > point to such a tz-file will allow us to use the systemd-timedated > > interface to set time zone. The changeable tz-file (located at > > /etc/...) can be altered by root and a specific service. Do you see > > any potential risk by doing so? > > consider turning off the sandboxing features, i.e. add a drop-in that > turns off ProtectSystem=, ProtectHome= and suchlike. Just wanted to give feedback that ProtectSystem= and ProtectHome= was turned off already, but we could no longer produce the problem we have seen. So case closed. BR, Christopher Wong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Need help detecting local/remote targets
On Wed, 21 Aug 2019 at 08:02:39 +0200, Ulrich Windl wrote: > >>> Mantas Mikulenas schrieb am 21.08.2019 um 06:07 in > Nachricht > : > > / and /usr are mounted by initramfs before systemd starts. > > And what about /run? /run is mounted by systemd as pid 1, but it is one of the "API file systems"[1] and is required to be a tmpfs, so listing a non-tmpfs /run in /etc/fstab is not a supported situation. As a result, it is always local. smcv [1] https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Environment Variables are not getting passed to a child script started from a service
I am having a unit file like below running on Ubuntu 16.04 with systemd version 229. [Unit] Description=Hadoop-Yarn-Resourcemanager Service [Service] Type=simple Environment=JAVA_HOME=/usr/lib/jvm/jdk1.8 Environment=YARN_USER=yarn Environment=YARN_IDENT_STRING=yarn Environment=YARN_PID_DIR=/var/run/hadoop-yarn Environment=YARN_LOG_DIR=/var/log/hadoop-yarn Environment=YARN_CONF_DIR=/etc/hadoop/conf Environment=HADOOP_LIBEXEC_DIR=/usr/lib/hadoop/libexec IgnoreSIGPIPE=false ExecStart=/home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-start.sh ExecStopPost=-/bin/bash /home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-poststop.sh ExecStopPost=-/bin/sleep 1 RestartSec=2s Restart=always [Install] WantedBy=multi-user.target hadoop-yarn-resourcemanager-sysd-start.sh looks like below #!/bin/bash echo "Running pre-steps for hadoop-yarn-resourcemanager" sudo mkdir -p $YARN_LOG_DIR sudo chown -R yarn:hadoop $YARN_LOG_DIR sudo mkdir -p $YARN_PID_DIR sudo chown yarn:yarn $YARN_PID_DIR echo "Starting hadoop-yarn-resourcemanager" sudo -u yarn /usr/lib/hadoop-yarn/sbin/yarn-daemon.sh start resourcemanager sleep 3 echo "Starting health check for hadoop-yarn-resourcemanager" /home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-health.sh res=$? sleep 1 exit $res yarn-daemon.sh has code like below #!/usr/bin/env bash echo "debrah $YARN_LOG_DIR $HADOOP_LIBEXEC_DIR" ... But I am observing the environment variable values are not getting passed to yarn-daemon.sh. Below are the logs Aug 21 16:06:14 vrni-platform systemd[1]: Stopped Hadoop-Yarn-Resourcemanager Service. Aug 21 16:06:14 vrni-platform systemd[1]: Started Hadoop-Yarn-Resourcemanager Service. Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + echo 'Running pre-steps for hadoop-yarn-resourcemanager' Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: Running pre-steps for hadoop-yarn-resourcemanager Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + sudo mkdir -p /var/log/hadoop-yarn Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + sudo chown -R yarn:hadoop /var/log/hadoop-yarn Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + sudo mkdir -p /var/run/hadoop-yarn Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + sudo chown yarn:yarn /var/run/hadoop-yarn Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + echo 'Starting hadoop-yarn-resourcemanager' Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: Starting hadoop-yarn-resourcemanager Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: + sudo -u yarn /usr/lib/hadoop-yarn/sbin/yarn-daemon.sh start resourcemanager Aug 21 16:06:14 vrni-platform hadoop-yarn-resourcemanager-sysd-start.sh[12333]: debrah Can someone let me know what is the correct way to declare the enviroment variable so that it gets passed to a child script started by a systemd service? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment Variables are not getting passed to a child script started from a service
Am 21.08.19 um 18:29 schrieb Debraj Manna: > I am having a unit file like below running on Ubuntu 16.04 with systemd > version 229. > > echo "Starting hadoop-yarn-resourcemanager" > sudo -u yarn /usr/lib/hadoop-yarn/sbin/yarn-daemon.sh start resourcemanager this crap triggers new sessions, replace it with proper systemd units and proper ordering ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deferring start of service until file exists
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
Re: [systemd-devel] Environment Variables are not getting passed to a child script started from a service
On Wed, Aug 21, 2019 at 7:30 PM Debraj Manna wrote: > I am having a unit file like below running on Ubuntu 16.04 with systemd > version 229. > > [Unit] > Description=Hadoop-Yarn-Resourcemanager Service > [Service] > Type=simple > Environment=JAVA_HOME=/usr/lib/jvm/jdk1.8 > Environment=YARN_USER=yarn > Environment=YARN_IDENT_STRING=yarn > Environment=YARN_PID_DIR=/var/run/hadoop-yarn > Environment=YARN_LOG_DIR=/var/log/hadoop-yarn > Environment=YARN_CONF_DIR=/etc/hadoop/conf > Environment=HADOOP_LIBEXEC_DIR=/usr/lib/hadoop/libexec > IgnoreSIGPIPE=false > ExecStart=/home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-start.sh > ExecStopPost=-/bin/bash > /home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-poststop.sh > ExecStopPost=-/bin/sleep 1 > RestartSec=2s > Restart=always > [Install] > WantedBy=multi-user.target > > hadoop-yarn-resourcemanager-sysd-start.sh looks like below > > #!/bin/bash > > echo "Running pre-steps for hadoop-yarn-resourcemanager" > sudo mkdir -p $YARN_LOG_DIR > sudo chown -R yarn:hadoop $YARN_LOG_DIR > sudo mkdir -p $YARN_PID_DIR > sudo chown yarn:yarn $YARN_PID_DIR > echo "Starting hadoop-yarn-resourcemanager" > sudo -u yarn /usr/lib/hadoop-yarn/sbin/yarn-daemon.sh start resourcemanager > sleep 3 > echo "Starting health check for hadoop-yarn-resourcemanager" > /home/ubuntu/build-target/cdh/yarn-rm/hadoop-yarn-resourcemanager-sysd-health.sh > res=$? > > Usually `sudo` resets all environment variables except whitelisted ones. That's not a systemd thing – pid1 *cannot* affect how environment variables are inherited. Don't use sudo in systemd startup scripts. Create the pid_dir using RuntimeDirectory= (or tmpfiles.d), then just start yarn-daemon from ExecStart directly with User=yarn. And probably more importantly, don't start multiple services from a single .service unit – it will never work well... (Chances are, if you do this, you won't even *need* a PIDFile because systemd will be able to track the process directly.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
