[systemd-devel] Question about service dependency handling in systemd-228
Hello everyone, I would like to have a question regarding to the building dependency and cycle dependency handling on systemd-228. In my system, I have some socket and service files, it has a cycle on socket target, when I run on system-228, systemd-228 throws [ 40.358582] systemd[1]: Set hostname to . [ 41.154231] systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped [ 41.297229] systemd[1]: sockets.target: Found ordering cycle on sockets.target/start [ 41.297236] systemd[1]: sockets.target: Found dependency on asi-My-5101.socket/start [ 41.297239] systemd[1]: sockets.target: Found dependency on My-sshd.target/start [ 41.297241] systemd[1]: sockets.target: Found dependency on My-syncd.service/start [ 41.297244] systemd[1]: sockets.target: Found dependency on My-nfs-client.service/start [ 41.297246] systemd[1]: sockets.target: Found dependency on My-handling.service/start [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5101 [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5010 [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5111 [ SKIP ] Ordering cycle found, skipping asi-vsftpd-MyIO_2.socket [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5110 [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5002 [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5100 [ SKIP ] Ordering cycle found, skipping Remo...ell Facilities Activation Socket [ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5011 [ SKIP ] Ordering cycle found, skipping My sshd target It said that there is an ordering on the sockets.target, then break the cycle and SKIP randomly starting other service => the system cannot start. However I did not meet the same issue on systemd-210 with the same my services and sockets. Systemd-210 does not break and skip, and my system can start well. My question is if there are any significant different about building tree dependency and handling cycle dependency between systemd-210 and systemd-228 that can lead to my current situation? I have checked the change log, source code but not found any useful info And what does the message "nss-lookup.target: Dependency Before=nss-lookup.target dropped" mean? I do not see it in systemd-210. Many thanks for your support, Best regards, Naru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] stacked automounts
Is there a way to have stacked automounts? In this example only /d is mounted when /d/l/1/ is accessed: LABEL=d/d xfs noatime,x-systemd.automount,x-systemd.idle-timeout=22 1 2 /d/i/1.iso /d/l/1 iso9660 ro,loop,x-systemd.automount,x-systemd.idle-timeout=11 0 0 In the logs I see: Set up automount d-l-1.automount. Unset automount d-l-1.automount. Olaf signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] what is the best way to connect to another user's service (when root)?
On the one hand, I understand your point. On the other hand, there are three other ways of doing this: systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid= systemctl --user ... su -l -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user" machinectl --uid= shell /bin/systemctl --user ... (I'm assuming the last way actually works. Does it?) So I thought that my suggestion was an even cleaner way to accomplish the same thing. I get that you don't want priv code to depend on unpriv code but systemctl is a command line tool. It's up to the user if they want to run it that way. On Fri, Nov 24, 2017 at 5:05 AM, Lennart Poettering wrote: > On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote: > > > Hi, > > > > More questions about the systemd user service. > > > > Inside a script running as root, I want to control another user's > service. > > > > I have found two ways to do this: > > > > systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid= > > systemctl --user ... > > > > or: > > > > su -l -c "XDG_RUNTIME_DIR=/run/user/ systemctl > --user > > ..." > > > > Both work. > > > > If there a better way to do this? > > > > My distros aren't recent enough to include "machinectl shell" but is that > > the recommended way now? > > > > machinectl --uid= shell /bin/systemctl --user ... > > > > Perhaps there is not enough demand to justify it, but I would love if the > > systemctl command itself had a way to specify that it should communicate > > with a different user's service rather than system service or the calling > > user's service. Something like: > > > > systemctl --uid= --user .. > > > > would be awesome. > > Hmm, sorry, but this is something we'll are unlikely to support in any > special way. Making privileged code a client of unpriveled user code > like this makes me feel very uncomfortable. Privileged code really > should not transition and block on unprivileged user code likes > this. Philosophically it has this feeling of being the wrong way > round: the unpriv code should ask the priv code what it should do, it > shouldn't be the priv code that asks the unpriv code, in any blocking > way... I mean, the unpriv code can ultimately do whatever it wants, > and priv code should not block on that for good. It's simply the wrong > way round to design such a system, if you follow what i mean. > > Usually most usecase like that are better solved by making things > asynchronous notifier based, and make the unpriv code just react to > notifications, instead of synchronous call-ins... > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] what is the best way to connect to another user's service (when root)?
On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote: > Hi, > > More questions about the systemd user service. > > Inside a script running as root, I want to control another user's service. > > I have found two ways to do this: > > systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/ --uid= > systemctl --user ... > > or: > > su -l -c "XDG_RUNTIME_DIR=/run/user/ systemctl --user > ..." > > Both work. > > If there a better way to do this? > > My distros aren't recent enough to include "machinectl shell" but is that > the recommended way now? > > machinectl --uid= shell /bin/systemctl --user ... > > Perhaps there is not enough demand to justify it, but I would love if the > systemctl command itself had a way to specify that it should communicate > with a different user's service rather than system service or the calling > user's service. Something like: > > systemctl --uid= --user .. > > would be awesome. Hmm, sorry, but this is something we'll are unlikely to support in any special way. Making privileged code a client of unpriveled user code like this makes me feel very uncomfortable. Privileged code really should not transition and block on unprivileged user code likes this. Philosophically it has this feeling of being the wrong way round: the unpriv code should ask the priv code what it should do, it shouldn't be the priv code that asks the unpriv code, in any blocking way... I mean, the unpriv code can ultimately do whatever it wants, and priv code should not block on that for good. It's simply the wrong way round to design such a system, if you follow what i mean. Usually most usecase like that are better solved by making things asynchronous notifier based, and make the unpriv code just react to notifications, instead of synchronous call-ins... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel