Dear Maintainer,

   * What led up to the situation?
I wanted to upgrade to Trixie.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
I run apt upgrade --without-new-pkgs
   * What was the outcome of this action?
The desktop restarted at the end closing everything but I was not warned in the release notes only in the terminal itself
   * What outcome did you expect instead?
Probably the same but with a warning in the release notes

Guillermo Torres Zamora wrote:

This doesn't match what I've seen in any of my (unofficial) tests,
including the one where I was specifically checking for this on a
default GNOME-on-Wayland setup: the old session was left running while
I finished tidying up after the upgrade.  What desktop environment are
you talking about?  (And what "warning" did it give in the terminal?)

This can be triggered if you specifically tell needrestart to restart
processes that are usually left un-restarted, but the package
needrestart probably isn't even installed on your machine.

On Fri, 1 Aug 2025 13:51:36 +0100 Justin B Rye  <justin.byam.rye@gmail.com> wrote:
 > Guillermo Torres Zamora wrote:
 > > I run apt upgrade --without-new-pkgs
 > >
 > > * What was the outcome of this action?
 > > The desktop restarted at the end closing everything but I was not
 > > warned in the release notes only in the terminal itself
 > >
 > > * What outcome did you expect instead?
 > > Probably the same but with a warning in the release notes
 >
 > This doesn't match what I've seen in any of my (unofficial) tests,
 > including the one where I was specifically checking for this on a
 > default GNOME-on-Wayland setup: the old session was left running while
 > I finished tidying up after the upgrade. What desktop environment are
 > you talking about? (And what "warning" did it give in the terminal?)
 >
 > This can be triggered if you specifically tell needrestart to restart
 > processes that are usually left un-restarted, but the package
 > needrestart probably isn't even installed on your machine.
 > --
 > JBR with qualifications in linguistics, experience as a Debian
 > sysadmin, and probably no clue about this particular package
 >
 >

Cinnamon desktop on Xorg and I do have install needrestart, which I
forgot about, so it's probably that.

On Fri, 1 Aug 2025, 16:31 Guillermo Torres Zamora, < torreszamoraguillermo@gmail.com> wrote:


Cinnamon desktop on Xorg and I do have install needrestart, which I

should the release-notes tell people to do something to needrestart to
prevent this happening?  or is this a bug in needsrestart?

Richard Lewis wrote:

Needrestart _shouldn't_ do this - it maintains a blacklist of types of
service that shouldn't be automatically restarted, which includes
display managers and so on - but it does allow users to override that
blacklist.  It would be useful to know whether Guillermo accidentally
ordered it to shoot him in the foot*, or whether it's weirdly buggy
(you'd think this kind of issue would already have been reported), or
whether it's a complete red herring after all and something else went
wrong.

While I'm trying to imagine a way of testing it, we might as well also
be thinking about what we might say in the Release Notes if necessary.
We do after all have that systemd-run trick lying around if we need
an antidote to offer in section 4.1.5.

  Users running GNOME [does it matter whether it's on Wayland?  Might
  this also apply to KDE?] who have activated [needrestart,
  bootsniper-tng, GNOME killing-spree mode...] may wish to protect
  themselves against the possibility of an accidentally restarted user
  session by running the upgrade from `screen` or `tmux` within a
  `systemd-run` wrapper (e.g. `systemd-run --scope --user screen`).

Except I never did really understand how that interacts with GNOME
killing-spree mode, and now I can't find all the Salsa discussions
from back in March.

(* As in the old slogan "Debian GNU/Linux: giving you the power to
shoot yourself in each toe individually!")

needrestart in the default config prompts what should be restarted.
I doubt intended behaviour of needrestart qualifies as a bug, and
it's users need to remember they have it.

Chris

Hi,

Am 2. August 2025 17:14:52 MESZ schrieb Chris Hofstaedtler <zeha@debian.org>:

At some time we had the recommendation, to start the upgrade from virtual console, not from X.
Maybe we need that to come back ....

I personally still do it like this.


Holger

On Sat, 2 Aug 2025 16:14:35 +0100 Justin B Rye  <justin.byam.rye@gmail.com> wrote:
 > Richard Lewis wrote:
 > >>> This can be triggered if you specifically tell needrestart to restart
 > >>> processes that are usually left un-restarted, but the package
 > >>> needrestart probably isn't even installed on your machine.
 > >>
 > >> Cinnamon desktop on Xorg and I do have install needrestart, which I
 > >> forgot about, so it's probably that.
 > >
 > > should the release-notes tell people to do something to needrestart to
 > > prevent this happening? or is this a bug in needsrestart?
 >
 > Needrestart _shouldn't_ do this - it maintains a blacklist of types of
 > service that shouldn't be automatically restarted, which includes
 > display managers and so on - but it does allow users to override that
 > blacklist. It would be useful to know whether Guillermo accidentally
 > ordered it to shoot him in the foot*, or whether it's weirdly buggy
 > (you'd think this kind of issue would already have been reported), or
 > whether it's a complete red herring after all and something else went
 > wrong.
 >
 > While I'm trying to imagine a way of testing it, we might as well also
 > be thinking about what we might say in the Release Notes if necessary.
 > We do after all have that systemd-run trick lying around if we need
 > an antidote to offer in section 4.1.5.
 >
 > Users running GNOME [does it matter whether it's on Wayland? Might
 > this also apply to KDE?] who have activated [needrestart,
 > bootsniper-tng, GNOME killing-spree mode...] may wish to protect
 > themselves against the possibility of an accidentally restarted user
 > session by running the upgrade from `screen` or `tmux` within a
 > `systemd-run` wrapper (e.g. `systemd-run --scope --user screen`).
 >
 > Except I never did really understand how that interacts with GNOME
 > killing-spree mode, and now I can't find all the Salsa discussions
 > from back in March.
 >
 > (* As in the old slogan "Debian GNU/Linux: giving you the power to
 > shoot yourself in each toe individually!")
 > --
 > JBR with qualifications in linguistics, experience as a Debian
 > sysadmin, and probably no clue about this particular package
 >
 >

Okay, I did a quick test on a VM and needrestart blacklist works properly.

By default, it restarts the services:

- accounts-daemon, avahi-daemon, colord, cups-browsed, cups, fwupd,
packagekit, polkit, power-profiles-daemon, systemd-journald,
systemd-manager, systemd-timesyncd, systemd-udevd, systemd-user, udisks2
and upower.

It excludes:

- dbus, getty@tty1, lightdm, ModemManager, NetworkManager,
systemd-logind and wpa_supplicant.

Restarting with the default list doesn't close the session and then
retriggering needrestart manually and selecting dbus restarts the session.

Yesterday, I think I just manually selected everything and shoot myself
in the foot because I don't always know 100% what I'm doing or remember
everything I have installed on my laptop.

Holger Wansing wrote:

Unfortunately if this was GNOME's killing-spree mode, being logged in
"outside" the graphical session wouldn't help, because these days with
desktop environment processes running as a big mess of independent
services instead of all being children of a window manager, logind
doesn't try to distinguish.  Under at least some circumstances (one of
them being if the option KillUserProcesses is set to "Yes", which has
at times been the upstream default), restarting GNOME sprays userspace
with kill signals to ensure no VT logins or cronjobs or detached tmux
sessions survive.

So in fact it would be a *bad* idea to advise users to start from a
virtual console, because they'll think that means they're free to log
out of their GNOME session halfway through the upgrade.

Fortunately the dist-upgrade *shouldn't* involve a restart, but just
as a precaution these days I always do it under fvwm3.

Hi Justin,

Am 3. August 2025 09:23:23 MESZ schrieb Justin B Rye <justin.byam.rye@gmail.com>:

Wow, this is getting way to complicated for me.
I'm out here...

Holger