Dear Maintainer,

When I performed an update with KDE Discover, I noticed it stalled at
99% complete status and would not finish. When I checked the process
tree with htop, I noticed the following lines from packagekitd and
needrestart:

   2629 root       20   0  492M  124M 79624 S  0.0  0.8  0:29.20 ├─ /usr/libexec/packagekitd
   2632 root       20   0  492M  124M 79624 S  0.0  0.8  0:00.00 │  ├─ /usr/libexec/packagekitd
   2634 root       20   0  492M  124M 79624 S  0.0  0.8  0:00.05 │  ├─ /usr/libexec/packagekitd
  14075 root       20   0  492M  124M 79624 S  0.0  0.8  0:05.78 │  ├─ /usr/libexec/packagekitd
  14090 root       20   0  494M 99648 50800 S  0.0  0.6  0:00.24 │  └─ /usr/libexec/packagekitd
  25864 root       20   0  494M 51924  2336 S  0.0  0.3  0:00.00 │     └─ /usr/libexec/packagekitd
  25872 root       20   0  2472   704   616 S  0.0  0.0  0:00.00 │        └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
  25873 root       20   0 35864 27816  6140 S  0.0  0.2  0:00.64 │           └─ /usr/bin/perl /usr/sbin/needrestart

It appears that packagekit is still running needrestart to ask if I
want to restart systemd services. However, this prompt is obviously not
visible to me through KDE Discover, so it's stuck waiting forever.

If I use kill on needrestart, the Discover session completes.

Since, this is an interaction between Discover, packagekit, apt and
needrestart (possibly others?), I'm not 100% sure this is the right
place for it. Feel free to reassign if I got it wrong.

Ryan

Hi Ryan,

needrestart should not block if it is run non-interactive. On Debian it
uses the debconf frontend which also has graphical frontends. Do you
get debconf dialogs in KDE Discover when installing/updating packages
at all? (Sorry I do not have an KDE environment for testing.)


Regards,
Thomas

Hi Ryan,

needrestart should not block if it is run non-interactive. On Debian it
uses the debconf frontend which also has graphical frontends. Do you
get debconf dialogs in KDE Discover when installing/updating packages
at all? (Sorry I do not have an KDE environment for testing.)


Regards,
Thomas

Hi,

could you check running needrestart as root on cli if you have any
pending restarts?

You might try to reinstall a lib to trigger needrestart (i.e. via apt-
get install --reinstall libnss3 - this *should* not break anything) to
force to get a pending restarts.

Please check if needrestart and debconf-kde-helper are working when
using KDE Discover afterwards.


Regards,
Thomas

So, I actually just installed my regular updates today with Discover and
noticed a few library changes. The update completed properly. If I run
needrestart after (or do an apt install), it confirms it wants to restart some
libraries. I can continue to install other packages with Discover as well.
So it looks like that package was all I needed.

Thanks,
Ryan

Dear Maintainer,

duplicate of <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977402>

but it does
- discover hangs at 100%

ps axf


LC_ALL=C.UTF-8 needrestart -r l -v
…

More info from today, where again the update is stalled due to the next
update

The message is from

which is the only available UI package:

Looking further into /usr/share/perl5/NeedRestart/UI/stdio.pm:
...

Combine that with


STDIN and STDOUT are both '/dev/pts/3' which is a pseudo TTY, so the
test evaluates to true and the code tries to read from that PTY; as the
message is not displayed anywhere visible and there is no way to
interact with needrestart from Discover the process hangs.

Philipp

Perhaps I spoke too hastily earlier, or perhaps the issue only manifests for
certain update sets. I have seen the issue again a couple times in the past
week or so.

When I performed a manual `apt install` to install a random package after, I
received a notice that a newer kernel is available. Perhaps that's it?

Also note that I have never actually received a desktop notification from
debconf-kde-helper, if that was supposed to be the intended behaviour, so
perhaps this bug should just be reassigned to that package?

Ryan