Re: [systemd-devel] When does a systemctl start ... returns to prompt?
Le mer. 29 août 2018 à 10:03, Michael Chapman a écrit : Thank you for the clarification. > > Question 2: how can I configure the prog_two/prog_three case, i.e. having > > them starting one after the other (= start prog_three when prog_two is > > done), and have the prompt return immediately > > You can use "systemctl --no-block" to have systemctl not wait for the > service to finish activating. The downside to this is that you will have > no indication of a problem if the service fails during activation. > But I will still see it via systemctl status prog_two.service, right? Since this usage (at least for me) only happens when testing, it would be fine (normally the service is ran via a timer so the problem of the prompt not returning does not matter) Again thank you for the help, it clarified a lot. Cheers Wojtek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] When does a systemctl start ... returns to prompt?
Hello everyone systemctl start myserv.service sometimes immediately returns to the shell prompt and sometimes stays until the program is done. Specifically, taking the example of two programs - prog_one which starts in the foreground and never ends, defined as ExecStart=/path/to/prog_one - prog_two and prog_three which are defined as Type=oneshot ExecStart=/path/to/prog_two ExecStartPost=/path/to/prog_three systemctl start prog_one.service immediately returns (and prog_one keeps running) systemctl start prog_two.service does not return, waits until prog_two and then progr_three finish before returning If I do not use a Type in the prog_one unit, the unit fails because prog_three is started right after prog_one is initialized (and still running) Question 1: what are the rules for systemctl start ... to immediately come back to the prompt or not Question 2: how can I configure the prog_two/prog_three case, i.e. having them starting one after the other (= start prog_three when prog_two is done), and have the prompt return immediately Cheers Wojtek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to create minimal portable services environments?
Hello everyone, v239 brought in portable services (a good description is at http://0pointer.net/blog/walkthrough-for-portable-services.html) and while I still cannot make it work (I do not have a /usr/lib/systemd/portablectl despite having systemd --version reporting 239, but this is going to be a separate question) I wanted to understand how to build a minimal portable service. A practical example could be dnsmasq. It is provided as a package and depends (apt show dnsmasq) on netbase, dnsmasq-base, init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6). These packages may further depend on something else. It also brings in a set of files into the system: root@srv ~# dpkg-query -L dnsmasq /. /etc /etc/default /etc/default/dnsmasq /etc/dnsmasq.conf /etc/dnsmasq.d /etc/dnsmasq.d/README /etc/init.d /etc/init.d/dnsmasq /etc/insserv.conf.d /etc/insserv.conf.d/dnsmasq /etc/resolvconf /etc/resolvconf/update.d /etc/resolvconf/update.d/dnsmasq /lib /lib/systemd /lib/systemd/system /lib/systemd/system/dnsmasq.service /usr /usr/lib /usr/lib/resolvconf /usr/lib/resolvconf/dpkg-event.d /usr/lib/resolvconf/dpkg-event.d/dnsmasq /usr/share /usr/share/dnsmasq /usr/share/dnsmasq/installed-marker /usr/share/doc /usr/share/doc/dnsmasq Some of these are existing directories, some new ones and then there are files (new, but possibly existing as well). *How should I create a filesystem which has only the files required by the packages (= the ones it brings in, as well as all the dependencies)?* I know that I can dbootstrap a new system and install there dnsmasq - and then hopefully use this as the tree to be attached via portablectl. This however means that I do not have a "dnsmasq" portable service but rather a "bionic install with dnsmasq installed on top". The main reason for me to use portable service is to create small packages which encompass my service, to be mounted on a more or less base core OS install (say, minimal bionic). This would allow to get rid of several nspawn containers which do exactly this (base OS + a package installed on top). One of the ideas I had (but which seems very wrong) is to have a copy of the core OS, then in another copy install the required packages, and then make a diff of the two directories. But this looks horrible and is hardly maintainable. I would very much appreciate any pointers or hints on how to approach this. Wojtek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to create minimal portable services environments?
Le mer. 29 août 2018 à 17:11, Steve Dodd a écrit : > On 29 August 2018 at 15:43, Steve Dodd wrote: > > Shouldn't be that hard to adapt one of the above for nspawn? > > nspawn is not the problem - portable services are. I use a minimal image with nspawn which is OK but portable services are intended to be even thinner: no need to bring in the OS, just the files needed to run the service (which are the program itself, dependencies not found in the host and unit files) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where does resolved takes its data from?
OK , I think I found the reason. I get the IP via DHCP, which also brings in the DNS servers (the two secondaries). This somehow gets used by resolved, as it puts the resolvers in /run/systemd/resolve/resolv.conf. Since /etc/hosts is linked to /run/systemd/resolve/stub-resolv.conf which just points to 127.0.0.53, I believe that resolved internallmy sees teh secondaries (provided by DHCP), shows this by putting them into /run/systemd/resolve/resolv.conf and 127.0.0.53 uses that information (also visible via resolvctl status). This makes sense, leaving /etc/systemd/resolved.conf for static configurations (no DHCP), and probably as a way to overwrite DHCP provided data. Sorry for the noise. Le mer. 5 sept. 2018 à 08:11, Wojtek Swiatek a écrit : > Hello everyone, > > I decided to clean up my DNS resolving mess and fully go the > systemd-resolved way = on every machine: > - have /etc/resolv.conf linked to /run/systemd/resolve/stub-resolv.conf > - have the resolver stub running on 127.0.0.53 > - provide internal upstream and fallback servers in > /etc/systemd/resolved.conf > - hope for the best > > "every machine" above are actually nspawn containers with their own IP > addresses (provided and resolved by the host, via dnsmasq) > I removed any other resolvers (if they were present), everything is under > networkd control. > > My first step was to have a broken machine (DNS wise), with a fully > commented out /etc/systemd/resolved.conf (as it is by default), expecting > not to be able to resolve anything and go from there. > > To my surprise google.com resolved fine. OK, this must be an invisible > default pointing to 8.8.8.8 or something like that (as the fallbacks are > still commented out). > > But I also tried to resolve an internal name, known only by the host and > secondary internal servers (which would be the upstream servers mentioned > above, when actually configured in /etc/systemd/resolved.conf). > > I have no idea how resolved managed to get information from other DNS > servers (whihc could be either the host, which runs dnsmasq on 0.0.0.0:53, > or the secondaries which run bind on their_IP:53)). > Where could that resolution come from? > > The situation on the machines, showing that resolved is the only one > resolver: > > root@dev ~# lsof -i -P -n > COMMANDPIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME > systemd-n 51 systemd-network 18u IPv6 56615 0t0 UDP > [fe80::685a:94ff:fecc:37ce]:546 > systemd-n 51 systemd-network 20u IPv4 59162 0t0 UDP > 10.200.0.50:68 > rsyslogd56 syslog8u IPv4 66478 0t0 UDP *:57004 > salt-mini 68root 21u IPv4 829402 0t0 TCP > 10.200.0.50:46988->52.210.137.123:4505 (ESTABLISHED) > systemd-r 2519 systemd-resolve 12u IPv4 1272287 0t0 UDP > 127.0.0.53:53 > systemd-r 2519 systemd-resolve 13u IPv4 1272288 0t0 TCP > 127.0.0.53:53 (LISTEN) > > > root@dev ~# ps -ef > UIDPID PPID C STIME TTY TIME CMD > root 1 0 0 Sep04 ?00:00:00 /lib/systemd/systemd > root18 1 0 Sep04 ?00:00:00 > /lib/systemd/systemd-journald > systemd+51 1 0 Sep04 ?00:00:00 > /lib/systemd/systemd-networkd > root52 1 0 Sep04 ?00:00:00 /usr/bin/python3 > /usr/bin/networkd-dispatcher > root53 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-logind > root54 1 0 Sep04 ?00:00:00 /usr/sbin/cron -f > message+55 1 0 Sep04 ?00:00:00 /usr/bin/dbus-daemon > --system --address=systemd: --nofork --nopidfile --systemd-activation > --syslog-only > syslog 56 1 0 Sep04 ?00:00:00 /usr/sbin/rsyslogd -n > root62 1 0 Sep04 ?00:00:00 /usr/bin/python > /usr/bin/salt-minion > root63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u > --noclear --keep-baud console 115200,38400,9600 vt220 > root6862 0 Sep04 ?00:00:34 /usr/bin/python > /usr/bin/salt-minion > root7168 0 Sep04 ?00:00:00 /usr/bin/python > /usr/bin/salt-minion > root 873 1 0 Sep04 pts/000:00:00 /usr/bin/fish > root 875 1 0 Sep04 ?00:00:00 /lib/systemd/systemd --user > root 876 875 0 Sep04 ?00:00:00 (sd-pam) > systemd+ 2519 1 0 07:42 ?00:00:00 > /lib/systemd/systemd-resolved > root 3352 873 0 08:06 pts/000:00:00 ps -ef > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Where does resolved takes its data from?
Hello everyone, I decided to clean up my DNS resolving mess and fully go the systemd-resolved way = on every machine: - have /etc/resolv.conf linked to /run/systemd/resolve/stub-resolv.conf - have the resolver stub running on 127.0.0.53 - provide internal upstream and fallback servers in /etc/systemd/resolved.conf - hope for the best "every machine" above are actually nspawn containers with their own IP addresses (provided and resolved by the host, via dnsmasq) I removed any other resolvers (if they were present), everything is under networkd control. My first step was to have a broken machine (DNS wise), with a fully commented out /etc/systemd/resolved.conf (as it is by default), expecting not to be able to resolve anything and go from there. To my surprise google.com resolved fine. OK, this must be an invisible default pointing to 8.8.8.8 or something like that (as the fallbacks are still commented out). But I also tried to resolve an internal name, known only by the host and secondary internal servers (which would be the upstream servers mentioned above, when actually configured in /etc/systemd/resolved.conf). I have no idea how resolved managed to get information from other DNS servers (whihc could be either the host, which runs dnsmasq on 0.0.0.0:53, or the secondaries which run bind on their_IP:53)). Where could that resolution come from? The situation on the machines, showing that resolved is the only one resolver: root@dev ~# lsof -i -P -n COMMANDPIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME systemd-n 51 systemd-network 18u IPv6 56615 0t0 UDP [fe80::685a:94ff:fecc:37ce]:546 systemd-n 51 systemd-network 20u IPv4 59162 0t0 UDP 10.200.0.50:68 rsyslogd56 syslog8u IPv4 66478 0t0 UDP *:57004 salt-mini 68root 21u IPv4 829402 0t0 TCP 10.200.0.50:46988->52.210.137.123:4505 (ESTABLISHED) systemd-r 2519 systemd-resolve 12u IPv4 1272287 0t0 UDP 127.0.0.53:53 systemd-r 2519 systemd-resolve 13u IPv4 1272288 0t0 TCP 127.0.0.53:53 (LISTEN) root@dev ~# ps -ef UIDPID PPID C STIME TTY TIME CMD root 1 0 0 Sep04 ?00:00:00 /lib/systemd/systemd root18 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-journald systemd+51 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-networkd root52 1 0 Sep04 ?00:00:00 /usr/bin/python3 /usr/bin/networkd-dispatcher root53 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-logind root54 1 0 Sep04 ?00:00:00 /usr/sbin/cron -f message+55 1 0 Sep04 ?00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only syslog 56 1 0 Sep04 ?00:00:00 /usr/sbin/rsyslogd -n root62 1 0 Sep04 ?00:00:00 /usr/bin/python /usr/bin/salt-minion root63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220 root6862 0 Sep04 ?00:00:34 /usr/bin/python /usr/bin/salt-minion root7168 0 Sep04 ?00:00:00 /usr/bin/python /usr/bin/salt-minion root 873 1 0 Sep04 pts/000:00:00 /usr/bin/fish root 875 1 0 Sep04 ?00:00:00 /lib/systemd/systemd --user root 876 875 0 Sep04 ?00:00:00 (sd-pam) systemd+ 2519 1 0 07:42 ?00:00:00 /lib/systemd/systemd-resolved root 3352 873 0 08:06 pts/000:00:00 ps -ef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Are there repeating monotonic timers?
Hello everyone I would like to have a timer which runs every 60 seconds after the machine is booted. I thought that OnBootSec would be the right parameter but this is s a one shot call - it starts 60 seconds after the boot and then the service is done (does not restart ever) Is there a way to start a service every 60 seconds (this is an example), short of using OnCalendar and fixed times (including /x notation, but then end up at fixed dates/times anyway)? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Are there repeating monotonic timers?
Le lun. 3 sept. 2018 à 17:30, Jérémy Rosen a écrit : > You can put multiple criterion in a single .timer > > In your case, combining OnBootSec and OnUnitActiveSec should do what you > want... > > Thank you - that was it. OnBootSec=60s OnUnitActiveSec=60s I did not realize that OnUnitActiveSec would be triggered by the OnBootSec-started service, and then triggered by its last run. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to add a second bridge to a nspawn container?
Hello everyone, I have an nspawn container which is currently connected to a bridge on the host: root@srv /e/s/nspawn# cat domotique.nspawn [Exec] Boot=yes [Network] Bridge=br0 #Bridge=wlx00c0ca384bd9 This results in a host0 interface being present in the container. Everything works. I now would like to add another interface in the container, which would be bridged with a wireless card on the host. The commented out line above is my attempt to add another bridge but it failed with -- Subject: Unit systemd-nspawn@domotique.service has begun start-up -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit systemd-nspawn@domotique.service has begun starting up. Jan 03 17:02:17 srv systemd-nspawn[17264]: Selected user namespace base 119472128 and range 65536. Jan 03 17:02:17 srv systemd-nspawn[17264]: Failed to add interface vb-domotique to bridge wlx00c0ca384bd9: Operation not supported Jan 03 17:02:17 srv systemd-udevd[17279]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 03 17:02:17 srv systemd-timesyncd[791]: Network configuration changed, trying to establish connection. Jan 03 17:02:17 srv networkd-dispatcher[906]: WARNING:Unknown index 26 seen, reloading interface list Jan 03 17:02:17 srv systemd-timesyncd[791]: Synchronized to time server 145.238.203.10:123 (ntp.obspm.fr). Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Main process exited, code=exited, status=1/FAILURE Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Failed with result 'exit-code'. Jan 03 17:02:17 srv systemd[1]: Failed to start Container domotique. I am not sure whether "Operation not supported" means that there is something wrong with that config? or that it is not possible to create a bridge to a wireless NIC? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
