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
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.
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
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
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
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
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
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
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
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,
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
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
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.
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
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.
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
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
17 matches
Mail list logo
