Re: [systemd-devel] ssh.service in rescue.target
Phillip Susi wrote: > > Simon McVittie writes: > > > The Debian/Ubuntu package for systemd already masks various services > > that are superseded by something in systemd, such as procps.service and > > rcS.service. It used to also mask all the services from initscripts, > > but that seems to have been dropped in version 243-5. > > Ahh, that explains why it seems to be implicitly masked on 18.04. > > > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services > > like killprocs, or perhaps the initscripts package should take over > > Sounds like it. > > >> initramfs-tools does not depend on initscripts, but *breaks* it, which > >> should mean it is not possible for both packages to be installed at the > >> same time. > > > > initramfs-tools only Breaks initscripts (<< 2.88dsf-59.3~), which means > > it is possible for both to be installed at the same time, as long as > > initscripts is at a sufficiently new version. > > Yes, but why is it listed as *depending* on initscripts when it only > breaks it ( and only an older version at that )? What package depends on initscripts? Does systemd depend on initscrips? Is it initramfs-tools? Does that dependency has something to do with /sbin/init? -- u34 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Simon McVittie writes: > The Debian/Ubuntu package for systemd already masks various services > that are superseded by something in systemd, such as procps.service and > rcS.service. It used to also mask all the services from initscripts, > but that seems to have been dropped in version 243-5. Ahh, that explains why it seems to be implicitly masked on 18.04. > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services > like killprocs, or perhaps the initscripts package should take over Sounds like it. >> initramfs-tools does not depend on initscripts, but *breaks* it, which >> should mean it is not possible for both packages to be installed at the >> same time. > > initramfs-tools only Breaks initscripts (<< 2.88dsf-59.3~), which means > it is possible for both to be installed at the same time, as long as > initscripts is at a sufficiently new version. Yes, but why is it listed as *depending* on initscripts when it only breaks it ( and only an older version at that )? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Am Mo., 9. Nov. 2020 um 18:25 Uhr schrieb Michael Biebl : > I guess this is kinda moot now, given that the initscripts package was > completely removed in Ubuntu 20.10 it seems. > Fwiw, I'd be surprised if there really are any packages in 20.04 still > depending on initscripts. > Maybe just purge the package (remove is not sufficient, initscripts > being conffiles and all) Hm, I guess Ubuntu has dropped the initscripts package for much longer already: At least since bionic: +sysvinit (2.88dsf-59.10ubuntu1) bionic; urgency=medium + + * Merge with Debian, restoring 6ac609340af19a8d021c5ab8fea50c65241d1d0b: +- When building for Ubuntu, skip all binaries except for sysvinit-utils. + + -- Adam Conrad Wed, 01 Nov 2017 15:00:29 -0600 So, Phillip, if you still have an initscripts package installed on 20.04, this is a left-over from previous dist-upgrades. Purge the package (along with sysv-rc etc, in case you still have them installed) Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Am Mo., 9. Nov. 2020 um 18:20 Uhr schrieb Michael Biebl : > > Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie : > > > > On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote: > > > I guess I'll try masking it. > > > > The Debian/Ubuntu package for systemd already masks various services > > that are superseded by something in systemd, such as procps.service and > > rcS.service. It used to also mask all the services from initscripts, > > but that seems to have been dropped in version 243-5. > > > > systemd-sysv-generator (which generates systemd service units corresponding > > to sysv-rc services) has stopped generating units for sysv-rc services that > > run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to > > rescue.target). killprocs runs in rc1. > > > > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services > > like killprocs, or perhaps the initscripts package should take over > > responsibility for masking rc1 services that it ships if they are not > > applicable to systemd, > > https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/ > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685 > > Masking those SysV init specific services was moved to initscripts a > long time ago (before I dropped those masks from the systemd package). > > Obviously I can't speak for the Ubuntu package I guess this is kinda moot now, given that the initscripts package was completely removed in Ubuntu 20.10 it seems. Fwiw, I'd be surprised if there really are any packages in 20.04 still depending on initscripts. Maybe just purge the package (remove is not sufficient, initscripts being conffiles and all) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie : > > On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote: > > I guess I'll try masking it. > > The Debian/Ubuntu package for systemd already masks various services > that are superseded by something in systemd, such as procps.service and > rcS.service. It used to also mask all the services from initscripts, > but that seems to have been dropped in version 243-5. > > systemd-sysv-generator (which generates systemd service units corresponding > to sysv-rc services) has stopped generating units for sysv-rc services that > run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to > rescue.target). killprocs runs in rc1. > > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services > like killprocs, or perhaps the initscripts package should take over > responsibility for masking rc1 services that it ships if they are not > applicable to systemd, https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685 Masking those SysV init specific services was moved to initscripts a long time ago (before I dropped those masks from the systemd package). Obviously I can't speak for the Ubuntu package ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote: > I guess I'll try masking it. The Debian/Ubuntu package for systemd already masks various services that are superseded by something in systemd, such as procps.service and rcS.service. It used to also mask all the services from initscripts, but that seems to have been dropped in version 243-5. systemd-sysv-generator (which generates systemd service units corresponding to sysv-rc services) has stopped generating units for sysv-rc services that run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to rescue.target). killprocs runs in rc1. Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services like killprocs, or perhaps the initscripts package should take over responsibility for masking rc1 services that it ships if they are not applicable to systemd, or perhaps systemd-sysv-generator should ignore services like killprocs that run in rc1? > apt-cache depends util-linux says that it does not > *depend* on it but *replaces* it. Doesn't that mean that when > util-linux is installed, initscripts should be removed? Not necessarily, it isn't the same as RPM's Obsoletes field. "util-linux Replaces initscripts" means that util-linux is allowed to overwrite files that were previously shipped in initscripts. The rest of initscripts is potentially still necessary (in fact it's unnecessary when booting with systemd, but necessary when booting with sysv-rc). Also, the Replaces is versioned: only old versions of initscripts are replaced, and new versions are unaffected. > initramfs-tools does not depend on initscripts, but *breaks* it, which > should mean it is not possible for both packages to be installed at the > same time. initramfs-tools only Breaks initscripts (<< 2.88dsf-59.3~), which means it is possible for both to be installed at the same time, as long as initscripts is at a sufficiently new version. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Michael Biebl writes: > Are you sure? > Which Ubuntu version is that? > At least in Debian, /etc/init.d/killprocs is shipped by "initscripts" > which is no longer installed by default. 20.04. apt-cache rdepends shows: Reverse Depends: sysv-rc util-linux hostapd wpasupplicant util-linux initramfs-tools base-files hostapd wpasupplicant sysvinit-utils initramfs-tools base-files console-setup-linux So it looks like it's a required package. I guess I'll try masking it. Hrm... odd... I wondered why util-linux would depend on initscripts... apt-cache depends util-linux says that it does not *depend* on it but *replaces* it. Doesn't that mean that when util-linux is installed, initscripts should be removed? And initramfs-tools does not depend on initscripts, but *breaks* it, which should mean it is not possible for both packages to be installed at the same time. WTF over? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Fri, Nov 6, 2020, 23:31 Phillip Susi wrote: > > Lennart Poettering writes: > > > Are you running systemd? If so, please get rid of "killproc". It will > > interfere with systemd's service management. > > I see.. apparently Ubuntu still has it around. How does systemd handle > it? For instance, if a user logged in and forked off a background > process, how does systemd make sure it gets killed when isolating to > rescue.target? Does it decide that it is still connected to ssh.service > and so won't kill it when isolating? I'd like to make sure anything > like that is killed and maybe restart sshd if needed. > No, user processes are moved to their own cgroup and unit (usually session-XX.scope nested under user-UID.slice) as soon as sshd calls pam_systemd during login. (This includes also the sshd "worker" process which handles that connection, which is the one calling PAM.) You can see the "contents" of sshd.service in its `systemctl status`, and you can run `systemd-cgls` to get a tree of all cgroups and which processes they contain. I don't exactly know in which conditions the session scopes (or the whole user slice) are stopped. But in any case, stopping a unit should kill all processes with no "leftovers". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Am Fr., 6. Nov. 2020 um 22:31 Uhr schrieb Phillip Susi : > > > Lennart Poettering writes: > > > Are you running systemd? If so, please get rid of "killproc". It will > > interfere with systemd's service management. > > I see.. apparently Ubuntu still has it around. Are you sure? Which Ubuntu version is that? At least in Debian, /etc/init.d/killprocs is shipped by "initscripts" which is no longer installed by default. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Lennart Poettering writes: > Are you running systemd? If so, please get rid of "killproc". It will > interfere with systemd's service management. I see.. apparently Ubuntu still has it around. How does systemd handle it? For instance, if a user logged in and forked off a background process, how does systemd make sure it gets killed when isolating to rescue.target? Does it decide that it is still connected to ssh.service and so won't kill it when isolating? I'd like to make sure anything like that is killed and maybe restart sshd if needed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Fr, 06.11.20 11:38, Phillip Susi (ph...@thesusis.net) wrote: > > What is "killprocs"? > > > > Is something killing services behind systemd's back? What's that > > about? > > It's the thing that kills all remaining processes right before shutdown > that we've had since the sysvinit? And also when isolating I suppose. Are you running systemd? If so, please get rid of "killproc". It will interfere with systemd's service management. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Fri, Nov 6, 2020, 18:38 Phillip Susi wrote: > > Lennart Poettering writes: > > > What is "killprocs"? > > > > Is something killing services behind systemd's back? What's that > > about? > > It's the thing that kills all remaining processes right before shutdown > that we've had since the sysvinit? But it was only needed *for* sysvinit. Systemd can already kill processes by itself. (The final cleanup before poweroff is done by systemd-shutdown; however, isolating does not reach this final stage – isolate only stops some units and starts other units.) I'm not sure if you're saying that the distro has re-added some redundant sysvinit stuff to the shutdown process? > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Lennart Poettering writes: > What is "killprocs"? > > Is something killing services behind systemd's back? What's that > about? It's the thing that kills all remaining processes right before shutdown that we've had since the sysvinit? And also when isolating I suppose. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org 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 (ph...@thesusis.net) 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
Lennart Poettering writes: > 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh.service in rescue.target
On Do, 29.10.20 14:31, Phillip Susi (ph...@thesusis.net) wrote: > I used to just have to add-wants ssh.service to rescue.target and I > could isolate to rescue mode for remote system maintainence without > loosing remote access to the server. After an upgrade, even though > ssh.service is wanted by rescue.target, it is still killed if I > isolate. How can I figure out why? 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. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
