Re: [systemd-devel] systemctl reboot/halt with non-privilege user
Am 28.10.20 um 12:40 schrieb An Liu: Hi, folks, I used to type systemctl reboot with non-privileged users, and to my surprise, the system goes down for the reboot. I've tested in both debian and centos 7, they act the same, however, systemctl halt will prompt you to enter administrator password to continue. which shows it's configureable Is it default behavior by design? I dont think a non-privileged user could reboot the system as he/she wishes. btw, I'm in an HPC related domain, if this behavior of systemctl is allowed, every single user could reboot the whole cluster as they wish, it's a disaster. https://bbs.archlinux.org/viewtopic.php?id=152565 ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Workaround for system upgrade bug suggestions
Am 03.11.20 um 14:56 schrieb Barry: On 3 Nov 2020, at 12:39, Colin Guthrie wrote: Barry wrote on 02/11/2020 22:20: What is the work around until the bug is fixed? I'd imagine you could just disable lingering for the users in question before running the dnf upgrade command? Not ideal but it's a workaround as you asked! Yep I guessed that would be the only thing to do. How do I get a list of all users with linger enabled? look in "/var/lib/systemd/linger" ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Mo, 02.11.20 16:13, Phillip Susi ([email protected]) wrote: > > Look at the logs? > > > > if they are not immeidately helpful, consider turning on debug logging > > in systemd first, and then redoing the action and then looking at the > > logs. You can use "systemd-analyze log-level debug" to turn on debug > > logging in PID 1 any time. > > It appears that systemd decides that ssh.service should remain running, > removes the redundant start job since it is already running, but > killprocs sends sshd a SIGTERM, so it shuts down, and systemd decides > not to restart it. iirc, there was a list of pids that would NOT be > killed at that stage... it appears that the pid for ssh.service isn't > getting placed in that list. How did that work again? What is "killprocs"? Is something killing services behind systemd's back? What's that about? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd vs. iwd
On Mo, 26.10.20 13:04, Bruce A. Johnson ([email protected]) wrote: > What are the state of things and the plan for the future with respect to > iwd and systemd-networkd? A couple of years ago, I put together a > satisfactory solution for my project in OpenEmbedded/Yocto using > systemd-networkd to manage the IP connections and wpa_supplicant to > manage the underlying Wi-Fi connection. Now it seems that Yocto has > dropped wpa_supplicant in favor of iwd, and the iwd folks seem to want > it to manage DHCP and routing in addition to the basic Level 2 > connectivity. It also seems like systemd-networkd can still do the stuff > it was doing before and that I can just use iwd to manage the Level 2. > Am I going to write myself into another dead end if I keep using > systemd-networkd for the network management and only use iwd for Level 2? Wifi can embed some DHCP info inside the wifi headers of packets already, to improve activation speed. That#s why the iwd people want to do DHCP themselves. This doesn't really make too much sense to me this way though, given the DHCP lease data is thus not seen/used by networkd (and it uses it for a lot of other stuff). In an ideal world networkd would understand enough wifi to do the magic dhcp stuff they do, so that networkd still processes the DHCP leases (and also can generate DHCP leases the way wifi likes it if the DHCP server logic is used). But so far noone worked on this, and not sure how this would related to iwd. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
