Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 04/06/2024 07:29, Vincent Lefevre wrote:

On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:

Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?


Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.


It is still a part of some systemd.service, try systemd-cgls. If mutt 
does not receive SIGTERM then it has no chance to stop. Perhaps that log 
entry just tells that a signal is sent to the whole cgroup.



What other processes survived first step? Are there something suspicious
before SIGKILL stage?


According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.


In the previous message you wrote about xdg-document-portal.

Perhaps timeouts are inconsistent for system and user services, so 
user@.service is killed before SIGTERM and SIGKILL stages completed 
withing the systemd user session. However I still expect SIGTERM before 
SIGKILL.


You may start a shell script that logs SIGTERM, but does not exit, to 
test if behavior is similar to your mutt issue.

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:
> Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?

Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.

> What other processes survived first step? Are there something suspicious
> before SIGKILL stage?

According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 31/05/2024 15:10, Vincent Lefevre wrote:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.


I can imagine that mutt may start a GUI handler for some attachment and 
that application uses XDG desktop portal. However I would expect that 
mutt just creates a file in /tmp, so it should not prevent mutt from 
quit on SIGTERM. Desktop environment should ensure that the handler runs 
independently of the mutt process (not as a child). Moreover that 
application should be stopped earlier during shutdown.


Do you see an attempt to send SIGTERM to mutt before timeout and 
SIGKILL? What other processes survived first step? Are there something 
suspicious before SIGKILL stage?

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 10:10:32 +0200, Vincent Lefevre wrote:
> On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> > Do you mean that mutt properly exits unless it receives SIGTERM in the
> > course of shutdown process?
> 
> I think that this was not the first time I did a shutdown while Mutt
> was still running. But this was the first time it did not exit.

I've tried a shutdown with Mutt still running in GNU Screen
a couple of times, and I got no timeout, i.e. Mutt exited as
expected.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> Do you mean that mutt properly exits unless it receives SIGTERM in the
> course of shutdown process?

I think that this was not the first time I did a shutdown while Mutt
was still running. But this was the first time it did not exit.

> I would try to enable debug log in mutt. There is a chance that
> networking is already disabled (or some other system unit important
> for mutt is already stopped) when systemd tries to kill mutt first
> time.

No, according to the logs, the network was stopped after SIGKILL
was sent to Mutt:

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
[...]
May 29 01:55:26 qaa systemd[1]: Stopping NetworkManager.service - Network 
Manager...
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2966] caught 
SIGTERM, shutting down normally.
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2975] dhcp4 
(eth0): canceled DHCP transaction

Note that mutt is not the only case of timeout at shutdown. There's
also

May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: State 
'stop-sigterm' timed out. Killing.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116031 (xdg-document-po) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116037 (fusermount3) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Main process 
exited, code=killed, status=9/KILL
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Failed with 
result 'timeout'.

This one is a known issue:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 30/05/2024 23:19, Vincent Lefevre wrote:


Have you tried to send SIGTERM to mutt?


I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the


Yes, SIGTERM is the default that systemd tries first. There are various 
kill modes, another signal may be configured for a unit, but I would 
leave defaults for user sessions.


Do you mean that mutt properly exits unless it receives SIGTERM in the 
course of shutdown process? I would try to enable debug log in mutt. 
There is a chance that networking is already disabled (or some other 
system unit important for mutt is already stopped) when systemd tries to 
kill mutt first time.

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-30 00:19:30 +0700, Max Nikulin wrote:
> On 29/05/2024 07:44, Vincent Lefevre wrote:
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> 
> Have you tried to send SIGTERM to mutt?

I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...

but this timed out, apparently due to the mutt process, which was
still running, so that systemd sent a SIGKILL (which succeeded).

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.

> If it ignores this signal or the reaction is some prompt then you
> need to find another way to stop mutt and to configure systemd user
> session to do it on logout (shutdown).

A SIGTERM normally kills mutt. In signal.c, signals are blocked
"while doing critical ops", namely for compressing/decompressing
(which I don't use) and when locking a mailbox (but I don't see
why this would have happened). Otherwise the signal handler just
does that:

static void exit_handler (int sig)
{
  curs_set (1);
  endwin (); /* just to be safe */

  exit_print_string (Caught_Signal_L10N ? Caught_Signal_L10N : "Caught signal 
");
#if SYS_SIGLIST_DECLARED
  exit_print_string (sys_siglist[sig]);
#else
#if (__sun__ && __svr4__)
  exit_print_string (_sys_siglist[sig]);
#else
#if (__alpha && __osf__)
  exit_print_string (__sys_siglist[sig]);
#else
  exit_print_int (sig);
#endif
#endif
#endif
  exit_print_string (Exiting_L10N ? Exiting_L10N : "...  Exiting.\n");
  exit (0);
}

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-29 16:13:05 -, Curt wrote:
> On 2024-05-29, Vincent Lefevre  wrote:
> > During the latest shutdown:
> >
> > May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of 
> > User vinc17...
> > [...]
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. 
> > Killing.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 
> > (mutt) with signal SIGKILL.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 
> > 'timeout'.
> > May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> > vinc17.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> > CPU time.
> > May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User 
> > Login Management...
> > May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager 
> > for UID 1000...
> > [...]
> >
> > Note: I had set DefaultTimeoutStopSec=20s because then is normally
> > sufficient.
> >
> > The mutt process was running in GNU Screen. The current mailbox
> > was just a local one. Mutt does no network connections (I do not
> > use IMAP). I general, I quit it before logging out, but this time,
> > it seems that I forgot.
> >
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> >
> 
> sudo journalctl -b-1?

See above. There's nothing else about mutt in the journal.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 29/05/2024 07:44, Vincent Lefevre wrote:

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?


Have you tried to send SIGTERM to mutt? If it ignores this signal or the 
reaction is some prompt then you need to find another way to stop mutt 
and to configure systemd user session to do it on logout (shutdown).

Re: timeout in shutdown, mutt killed by SIGKILL

[Curt]

On 2024-05-29, Vincent Lefevre  wrote:
> During the latest shutdown:
>
> May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
> vinc17...
> [...]
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
> with signal SIGKILL.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
> May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> vinc17.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> CPU time.
> May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
> Management...
> May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
> UID 1000...
> [...]
>
> Note: I had set DefaultTimeoutStopSec=20s because then is normally
> sufficient.
>
> The mutt process was running in GNU Screen. The current mailbox
> was just a local one. Mutt does no network connections (I do not
> use IMAP). I general, I quit it before logging out, but this time,
> it seems that I forgot.
>
> But I don't understand why there was a timeout. Does this mean that
> mutt didn't react to SIGTERM? Any reason?
>

sudo journalctl -b-1?

timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

During the latest shutdown:

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...
[...]
May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
UID 1000...
[...]

Note: I had set DefaultTimeoutStopSec=20s because then is normally
sufficient.

The mutt process was running in GNU Screen. The current mailbox
was just a local one. Mutt does no network connections (I do not
use IMAP). I general, I quit it before logging out, but this time,
it seems that I forgot.

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How can I get verbose shutdown from the GUI (Mate)?

[debian-user]

Ottavio Caruso  wrote:
> Am 03/10/2023 um 10:43 schrieb Bret Busby:
> > Also, why do you not use, instead of the command that you specified,
> > shutdown -h
> > or, (if instead, wanted, for example, after doing a kernel update)
> > shutdown -r
> > ?  
> 
> Because all of these are just an alias to systemctl poweroff as per 
> systemctl man page.

But shutdown -h or halt or reboot is less to type, so your explanation
explains the effect but not the reason for using the longer version.

Re: How can I get verbose shutdown from the GUI (Mate)?

[David Wright]

On Tue 03 Oct 2023 at 13:15:48 (+), Ottavio Caruso wrote:
> Am 03/10/2023 um 11:47 schrieb Ottavio Caruso:
> > Am 03/10/2023 um 10:43 schrieb Bret Busby:
> > > Also, why do you not use, instead of the command that you specified,
> > > shutdown -h
> > > or, (if instead, wanted, for example, after doing a kernel update)
> > > shutdown -r
> > > ?
> > 
> > Because all of these are just an alias to systemctl poweroff as
> > per systemctl man page.
> 
> Sorry I said alias, I mean link.
> 
> $ ls -l `which shutdown`
> lrwxrwxrwx 1 root root 14 Jun 18 15:55 /usr/sbin/shutdown -> /bin/systemctl
> $ ls -l `which poweroff`
> lrwxrwxrwx 1 root root 14 Jun 18 15:55 /usr/sbin/poweroff -> /bin/systemctl
> $ ls -l `which halt`
> lrwxrwxrwx 1 root root 14 Jun 18 15:55 /usr/sbin/halt -> /bin/systemctl

And observe that:

  $ ls -l /usr/sbin/reboot 
  lrwxrwxrwx 1 root root 14 Jun 18 09:55 /usr/sbin/reboot -> /bin/systemctl
  $ 

but one of the first things systemctl will do is to find out by which
name it was called, and act accordingly. That's pretty common
behaviour in un*x (think busybox).

Cheers,
David.

Re: How can I get verbose shutdown from the GUI (Mate)?

[Bret Busby]

On 3/10/23 17:14, Ottavio Caruso wrote:

Hi,

if  open a terminal window and type:

$ sudo systemctl poweroff

I can see what is going on and sometimes it takes almost a minute to 
power the laptop off.


If I press CTRL+ALT+DELETE from the GUI (Mate), the screen goes 
completely blank and I have no idea if the laptop is completely off or 
just thinking about it.


Is there a way to force verbosity during shutdown without opening a 
terminal window or creating a keyboard shortcut?


Thanks

It is not the answer to your question, but, it may be the answer that 
you seek;


"the screen goes completely blank and I have no idea if the laptop is 
completely off or just thinking about it."


Does your laptop not have, either in the power switch, or, elsewhere, an 
LED, that is lit when the computer is powered on, and, is dark when the 
computer is powered off?


I note that you do not specify the model of laptop that you have, but, 
on the two laptops that I currently have running - an HP laptop and an 
Acer Aspire V3-772G, the power switch incorporates an LED that acts as I 
have described. Also, on the Acre, at the front of the base, is a set of 
three LED's that clearly show whether the computer is powered on.


In Mate 1.26.0, I have a functionality to add functions to the panel, 
including "Shut down the computer", which has an icon like an electric 
light switch, that I sometimes use.


Also, why do you not use, instead of the command that you specified,
shutdown -h
or, (if instead, wanted, for example, after doing a kernel update)
shutdown -r
?

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..

Re: How can I get verbose shutdown from the GUI (Mate)?

[Max Nikulin]

On 03/10/2023 16:14, Ottavio Caruso wrote:


$ sudo systemctl poweroff

...
Is there a way to force verbosity during shutdown without opening a 
terminal window or creating a keyboard shortcut?


Perhaps all you need is

sudo journalctl -b -1 -e

when you boot your machine next time. Likely some systemd unit can not 
be properly stopped and it cause 1.5 min pause before killing of 
remaining processes.

Re: Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.

[Timothy M Butterworth]

On Sun, Mar 26, 2023 at 11:33 PM Ram Ramesh  wrote:

> Hi Ramesh,
>
> this might help. The bug is fixed with kernel 6.0.2-1
>
>  https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1
>
> All the best to you
> Eike
>
> Elke,
>
> Thanks. v6.1 is available on bullseye-backports. I installed it and the
> trouble is gone now.
>
> BTW, does non-free firmware tied to kernel version?
>
> I use firmware-realtek to deal with my dragon 2.5G NIC that seems to be
> unstable without realtek-firmware. I want to make sure I use the correct
> version (for linux v6.1), if there is such a requirement.
>

You will have to add and enable the non-free-firmware repo.
deb http://deb.debian.org/debian/ bookworm main non-free contrib
non-free-firmware

Binary Blobs are not directly tied to a kernel version. Since the kernel
became modular drivers and firmware are able to be developed and released
on their own schedule.


> Regards
> Ramesh
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.

[Ram Ramesh]

Hi Ramesh,

this might help. The bug is fixed with kernel 6.0.2-1

https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1

All the best to you
Eike


Elke,

Thanks. v6.1 is available on bullseye-backports. I installed it and the 
trouble is gone now.


BTW, does non-free firmware tied to kernel version?

I use firmware-realtek to deal with my dragon 2.5G NIC that seems to be 
unstable without realtek-firmware. I want to make sure I use the correct 
version (for linux v6.1), if there is such a requirement.


Regards
Ramesh

Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.

[Eike Lantzsch KY4PZ]

On Sonntag, 26. März 2023 18:08:15 -04 Ram Ramesh wrote:
> I wanted to upgrade my server from 10 year old HW to something newer.
> THis server runs debian bullseye with v5.19 kernel from backports.
[snip]
> 
> The only trouble I have is that it refuses to
> reboot/shutdown/poweroff. It seem to go through all steps and reach
> the end but seem to get stuck in this endless cycle complaining about
> some blkdev issue.  Here are the last lines printed on the console
> that shows the cycle
> 
> [OK] Reached target Power-off
> [67652.NN] block device autoloading is deprecated and will be
> removed
> 
> [67667.NN] blkdev_get_no_open: 119 callbacks suppressed
>  different  and number of callbacks being slightly different>
> 
> I assume by "[OK]..."  line that we are really at the end of shut down
> process. When I turn off physically using power switch and reboot, I
> do not get any fsck error messages. So, I assume that filesystems are
> safe and kernel is somehow lost in some thread and cannot end the
> reboot process.
> 
> Any ideas what I can do?
> 
> Regards
> Ramesh

Hi Ramesh,
this might help. The bug is fixed with kernel 6.0.2-1

https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1[1]

All the best to you
Eike
-- 
Eike Lantzsch KY4PZ / ZP5CGE



[1] https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1

I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.

[Ram Ramesh]

I wanted to upgrade my server from 10 year old HW to something newer. 
THis server runs debian bullseye with v5.19 kernel from backports. Here 
is the list of items I got in the upgraded system


1. Intel z690 mother board (asrock steel legend)
2. Core i3-13100 cpu
3. Super Flower 650W PSU,
4. G.SKILL DDR4 RAM
5. 2x SK hynix P31 nvme SSD 1TB each.

I reused these from old build

1. Geforce GT 630 video card
2. SAS9211i HBA card for extra SATA ports
3. All my large spinning drives that contained data in RAID6 and RAID1

I made a raid1 on mvme ssd and  created 3 partitions. In one I installed 
debian testing (bookworm with v6.1 kernel) and in another, I image 
copied the old installation I had before the HW upgrade. Debian bookworm 
runs fine and reboots/shutsdown as expected. My old system copied over 
also works fine for most part. It boots and runs everything that I care 
about. All my RAID disks are working. No issue as long as it runs.


The only trouble I have is that it refuses to reboot/shutdown/poweroff. 
It seem to go through all steps and reach the end but seem to get stuck 
in this endless cycle complaining about some blkdev issue.  Here are the 
last lines printed on the console that shows the cycle


   [OK] Reached target Power-off
   [67652.NN] block device autoloading is deprecated and will be
   removed
   
   [67667.NN] blkdev_get_no_open: 119 callbacks suppressed
   

I assume by "[OK]..."  line that we are really at the end of shut down 
process. When I turn off physically using power switch and reboot, I do 
not get any fsck error messages. So, I assume that filesystems are safe 
and kernel is somehow lost in some thread and cannot end the reboot 
process.


Any ideas what I can do?

Regards
Ramesh

Re: How to investigate sudden shutdown?

[David Wright]

On Thu 15 Dec 2022 at 16:12:32 (+0100), Tobias Diekershoff wrote:
> 
> > > perhaps someone of you can help me with tool / log file I have not 
> > > investigated
> > > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma 
> > > as main
> > > desktop environment and from time to time it just turn off without prior
> > > indication to do so.
> >
> > How old is the machine?
> 
> About 5 years

Ridiculously considered quite old for a laptop (mine are 5, 9 and 18).

> > Spinning rust or SSD?
> 
> SSD
> 
> > How have the battery and power handling been performing recently?
> 
> Well, no problems there.
> 
> > What type of connector is used for the AC power adapter?
> 
> It's a German Schuko connector.

Actually I meant the other end. Mine have three different types. The
newest has USB-C. They aren't the most reliably mechanically seated.
That machine was retired from business work on account of the HDMI
socket being unreliable, but all the sockets are as bad now.

The middle one got its power through the pseudo-USB-A connector
used for a while by Lenovo. It now has to run with the weight of
the machine trapping the power cable underneath, keeping just
the right torsion on the connector.

The only one that has a reliable connector is the oldest, which uses
the age-old coaxial barrel connector. The battery is dead, but this
is the only one of the three laptops that can be used on the lap.

> > > It it not particular warm before and journalctl / dmsg logs are looking
> > > unsuspicious around these sudden shutdowns for me.
> > >
> > > Any pointer what else could be investigated (and I do realize that these 
> > > are
> > > very vague symptoms) would be appreciated!
> >
> > Do shutdowns occur only on AC, or only on battery, or both?
> 
> Both, though the notebook runs on AC most of the time.
> 
> > Do the shutdowns coincide with moments of high load?
> 
> Not that I remember.
> 
> > Do they occur when you adjust the angle of the screen?
> 
> No.

My deceased 2008 Dell would sometimes power off when the screen
was adjusted. Eventually the screen would blank a few seconds
after power-on, unless the machine had been left for a week or so
without power, when the screen might stay lit for a minute or two.

> > Do they occur when the machine is mechanically undisturbed,
> > ie when it's sitting on a table?
> 
> Yes

Not much of a hint, from these replies, of what's causing your
problem. (I'm assuming that the symptom is sudden total power
loss, just like pulling the power plug out of a desktop PC.)

Cheers,
David.

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

Hey Alexander!

> > perhaps someone of you can help me with tool / log file I have not 
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
> 
> Does it power off unexpectedly while you actively working on it, or you just 
> see it powered off when you check it after a while?

Yes to both.

> These kinds of symptoms are hard to diagnose and usually indicate a hardware 
> problem.
> Please, give us more information about your laptop. You can use "inxi" 
> utility for that:
>     # inxi -a -v8 -z -za
> 
> You can send the output from "inxi" to paste service[1] and provide us with 
> just a link to it in next mail.

Here is the output
https://paste.debian.net/hidden/b7901559/

> Is laptop's battery(-ies) in good shape, i.e. it can sustain laptop at least 
> for a few minutes with PSU disconnected?

Yes, the batteries last for at least 3-4 hours still.

> If battery is dead, disconnect the battery and try to reproduce the issue 
> with only PSU connected.
>  
> > It it not particular warm before and journalctl / dmsg logs are looking
> > unsuspicious around these sudden shutdowns for me.
> > 
> > Any pointer what else could be investigated (and I do realize that these are
> > very vague symptoms) would be appreciated!
> A good place to start is to check journald logs for previous boot:
>     # journalctl --boot -1

Thanks for that hint, I'll have a look when the shutdown happens next time. 
Right now I don't have the time to figure out which last boot process was the 
last that failed ;-)
  Tobias

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

Hey David!

> > perhaps someone of you can help me with tool / log file I have not 
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
>
> How old is the machine?

About 5 years

> Spinning rust or SSD?

SSD

> How have the battery and power handling been performing recently?

Well, no problems there.

> What type of connector is used for the AC power adapter?

It's a German Schuko connector.

> > It it not particular warm before and journalctl / dmsg logs are looking
> > unsuspicious around these sudden shutdowns for me.
> >
> > Any pointer what else could be investigated (and I do realize that these are
> > very vague symptoms) would be appreciated!
>
> Do shutdowns occur only on AC, or only on battery, or both?

Both, though the notebook runs on AC most of the time.

> Do the shutdowns coincide with moments of high load?

Not that I remember.

> Do they occur when you adjust the angle of the screen?

No.

> Do they occur when the machine is mechanically undisturbed,
> ie when it's sitting on a table?

Yes

Thanks!
  Tobias

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

 Gesendet: Mittwoch, 14. Dezember 2022 um 10:00 Uhr

> On Wed, Dec 14, 2022 at 01:40:06PM +0500, Alexander V. Makartsev wrote:
> > On 14.12.2022 12:22, Tobias Diekershoff wrote:
> > > Hey everyone,
> > >
> > > perhaps someone of you can help me with tool / log file I have not 
> > > investigated
> > > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma 
> > > as main
> > > desktop environment and from time to time it just turn off without prior
> > > indication to do so.
> > Does it power off unexpectedly while you actively working on it, or you just
> > see it powered off when you check it after a while?
> 
> As another avenue: have you tried to run something else (e.g. memtest) on the
> machine for a while?

Good thought! I had almost forgot about memtest... will try that when there is 
some
time to spare to have it running for a while.

Thanks!
  Tobias

Re: How to investigate sudden shutdown?

[David Wright]

On Wed 14 Dec 2022 at 08:22:01 (+0100), Tobias Diekershoff wrote:
> 
> perhaps someone of you can help me with tool / log file I have not 
> investigated
> so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> main
> desktop environment and from time to time it just turn off without prior
> indication to do so.

How old is the machine?
Spinning rust or SSD?
How have the battery and power handling been performing recently?
What type of connector is used for the AC power adapter?

> It it not particular warm before and journalctl / dmsg logs are looking
> unsuspicious around these sudden shutdowns for me.
> 
> Any pointer what else could be investigated (and I do realize that these are
> very vague symptoms) would be appreciated!

Do shutdowns occur only on AC, or only on battery, or both?
Do the shutdowns coincide with moments of high load?
Do they occur when you adjust the angle of the screen?
Do they occur when the machine is mechanically undisturbed,
ie when it's sitting on a table?

By now you've probably surmised that my suspicions would fall
on the power handling. That's from my experience running laptops.

Cheers,
David.

Re: How to investigate sudden shutdown?

[tomas]

On Wed, Dec 14, 2022 at 01:40:06PM +0500, Alexander V. Makartsev wrote:
> On 14.12.2022 12:22, Tobias Diekershoff wrote:
> > Hey everyone,
> > 
> > perhaps someone of you can help me with tool / log file I have not 
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
> Does it power off unexpectedly while you actively working on it, or you just
> see it powered off when you check it after a while?

As another avenue: have you tried to run something else (e.g. memtest) on the
machine for a while?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to investigate sudden shutdown?

[Alexander V. Makartsev]

On 14.12.2022 12:22, Tobias Diekershoff wrote:

Hey everyone,

perhaps someone of you can help me with tool / log file I have not investigated
so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as main
desktop environment and from time to time it just turn off without prior
indication to do so.
Does it power off unexpectedly while you actively working on it, or you 
just see it powered off when you check it after a while?
These kinds of symptoms are hard to diagnose and usually indicate a 
hardware problem.
Please, give us more information about your laptop. You can use "inxi" 
utility for that:

    # inxi -a -v8 -z -za

You can send the output from "inxi" to paste service[1] and provide us 
with just a link to it in next mail.


Is laptop's battery(-ies) in good shape, i.e. it can sustain laptop at 
least for a few minutes with PSU disconnected?
If battery is dead, disconnect the battery and try to reproduce the 
issue with only PSU connected.



It it not particular warm before and journalctl / dmsg logs are looking
unsuspicious around these sudden shutdowns for me.

Any pointer what else could be investigated (and I do realize that these are
very vague symptoms) would be appreciated!

A good place to start is to check journald logs for previous boot:
    # journalctl --boot -1

"-1" is an index, so "0" is current boot, "-2" is two boots prior, etc.


[1] https://paste.debian.net/

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀https://www.debian.org
⠈⠳⣄

How to investigate sudden shutdown?

[Tobias Diekershoff]

Hey everyone,

perhaps someone of you can help me with tool / log file I have not investigated
so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as main
desktop environment and from time to time it just turn off without prior
indication to do so.

It it not particular warm before and journalctl / dmsg logs are looking
unsuspicious around these sudden shutdowns for me.

Any pointer what else could be investigated (and I do realize that these are
very vague symptoms) would be appreciated!

Thanks for reading, have a nice day!
  Tobias

--
Bōsī se sȳrī glaesās

Re: How to check for scheduled shutdown

[songbird]

Greg Wooledge wrote:
> On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
>> Hm. With SysV, you can't either (spoiler alert: the shutdown process
>> itself is the one doing the timing by sleeping until fulfillment of
>> its task). But you always can cancel it (shutdown -c with SysV, dunno,
>> again, with systemd).
>
> The systemd shutdown(8) man page has a -c option for canceling a pending
> shutdown.  I have not tested this.

  it has always worked for me.


  songbird

Re: How to check for scheduled shutdown

[Anssi Saari]

Sven Joachim  writes:

> Perhaps that the --show option was only added in systemd 250 and is not
> available in Bullseye and older Debian releases.

Except as a backport, Bullseye backports has systemd 251.3.

Re: How to check for scheduled shutdown

[Kamil Jońca]

Sven Joachim  writes:

[...]
>
> Perhaps that the --show option was only added in systemd 250 and is not
> available in Bullseye and older Debian releases.
>
> Cheers,
>Sven

Ach, indeed. Sorry.
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: How to check for scheduled shutdown

[Urs Thuermann]

Kamil Joñca  writes:

> kjonca@alfa:~%man shutdown
> SHUTDOWN(8)   
>     
> shutdown  
> 
> SHUTDOWN(8)
> 
> NAME
>shutdown - Halt, power off or reboot the machine
> [...]
> OPTIONS
> [...]
>--show
>Show a pending shutdown action and time if there is any.
> 
> kjonca@alfa:~%sudo shutdown --show
> No scheduled shutdown.
> 
> Am I overlooked something?

On my machine, the man page doesn't mention --show.

$ cat /etc/debian_version 
11.5
$ man shutdown | tail -n1
    systemd 247    SHUTDOWN(8)
$ /sbin/shutdown --show
/sbin/shutdown: unrecognized option '--show'


urs

Re: How to check for scheduled shutdown

[Greg Wooledge]

On Tue, Nov 22, 2022 at 10:11:15PM +0100, Ximo wrote:
> El 22/11/2022 a las 13:23, Urs Thuermann escribió:
> > After shutdown -h  I see no way to see this scheduled shutdown.
> > Before systemd, I could always see the shutdown process with its
> > arguments using ps(1).
> > 
> 
> # date --date @$(head -1 /run/systemd/shutdown/scheduled |cut -c6-15)

That looks quite fragile.  If the output format changes even slightly,
it'll start to give wrong answers.

In order to offer a better solution, I'd need to *see* one of these
files.  Which in turn apparently means I need to generate one.  So I guess
I get to test that "cancel" option after all.

unicorn:~$ sudo shutdown -r 23:59
[sudo] password for greg: 
Reboot scheduled for Tue 2022-11-22 23:59:00 EST, use 'shutdown -c' to cancel.
unicorn:~$ cat /run/systemd/shutdown/scheduled 
USEC=166917954000
WARN_WALL=1
MODE=reboot

OK.  I can work with that.

unicorn:~$ date -d @"$(awk -F= '/^USEC=/ {print $2/100}' 
/run/systemd/shutdown/scheduled)"
Tue Nov 22 23:59:00 EST 2022
unicorn:~$ sudo shutdown -c
unicorn:~$ cat /run/systemd/shutdown/scheduled
cat: /run/systemd/shutdown/scheduled: No such file or directory

Ironically, the "sudo shutdown -c" command blasted a message onto every
terminal EXCEPT the one where I ran the command.  Rather annoying.

A solution built around "dotting in" the file in a shell would also work,
but that's quite a bit more dangerous if the output format changes, or if
I'm only seeing a "best case scenario" here.  Before going there, I would
want to check the systemd source code to see whether this file is written
in a way that's guaranteed to be safe for a shell to dot in.  That's more
effort than I care to put into this right now.

Re: How to check for scheduled shutdown

[Charles Curley]

On Tue, 22 Nov 2022 21:11:55 +0100
Sven Joachim  wrote:

> > kjonca@alfa:~%sudo shutdown --show
> > No scheduled shutdown.
> >
> > Am I overlooked something?  
> 
> Perhaps that the --show option was only added in systemd 250 and is
> not available in Bullseye and older Debian releases.

I certainly don't see it on Bullseye.

root@ideapc:~# cat /etc/debian_version 
11.5
root@ideapc:~# shutdown --show
shutdown: unrecognized option '--show'
root@ideapc:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: How to check for scheduled shutdown

[Ximo]

El 22/11/2022 a las 13:23, Urs Thuermann escribió:

After shutdown -h  I see no way to see this scheduled shutdown.
Before systemd, I could always see the shutdown process with its
arguments using ps(1).



# date --date @$(head -1 /run/systemd/shutdown/scheduled |cut -c6-15)

Re: How to check for scheduled shutdown

[Sven Joachim]

On 2022-11-22 20:18 +0100, Kamil Jońca wrote:

> Urs Thuermann  writes:
>
>> After shutdown -h  I see no way to see this scheduled shutdown.
>> Before systemd, I could always see the shutdown process with its
>> arguments using ps(1).
>
> Hm.
> kjonca@alfa:~%man shutdown
> SHUTDOWN(8)   
> 
> shutdown  
>     
> SHUTDOWN(8)
>
> NAME
>shutdown - Halt, power off or reboot the machine
> [...]
> OPTIONS
> [...]
>--show
>Show a pending shutdown action and time if there is any.
>
> kjonca@alfa:~%sudo shutdown --show
> No scheduled shutdown.
>
> Am I overlooked something?

Perhaps that the --show option was only added in systemd 250 and is not
available in Bullseye and older Debian releases.

Cheers,
   Sven

Re: How to check for scheduled shutdown

[tomas]

On Tue, Nov 22, 2022 at 08:18:31PM +0100, Kamil Jońca wrote:
> Urs Thuermann  writes:
> 
> > After shutdown -h  I see no way to see this scheduled shutdown.
> > Before systemd, I could always see the shutdown process with its
> > arguments using ps(1).
> 
> Hm.
> kjonca@alfa:~%man shutdown
> SHUTDOWN(8)   
> 
> shutdown  
>         
> SHUTDOWN(8)
> 
> NAME
>shutdown - Halt, power off or reboot the machine
> [...]
> OPTIONS
> [...]
>--show
>Show a pending shutdown action and time if there is any.
> 
> kjonca@alfa:~%sudo shutdown --show
> No scheduled shutdown.
> 
> Am I overlooked something?

Ah, this one, again, from the systemd side...

Although, on the SysV side one could try to limp along with
something like

  sudo cat /proc/$(cat /var/run/shutdown.pid)/cmdline

:-)

(Now the explicit path of shutdown's PID might be in itself a
Debianism)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to check for scheduled shutdown

[Kamil Jońca]

Urs Thuermann  writes:

> After shutdown -h  I see no way to see this scheduled shutdown.
> Before systemd, I could always see the shutdown process with its
> arguments using ps(1).

Hm.
kjonca@alfa:~%man shutdown
SHUTDOWN(8) 
  shutdown  

    SHUTDOWN(8)

NAME
   shutdown - Halt, power off or reboot the machine
[...]
OPTIONS
[...]
   --show
   Show a pending shutdown action and time if there is any.

kjonca@alfa:~%sudo shutdown --show
No scheduled shutdown.

Am I overlooked something?

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: How to check for scheduled shutdown

[tomas]

On Tue, Nov 22, 2022 at 12:29:49PM -0500, Greg Wooledge wrote:
> On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
> > Hm. With SysV, you can't either [change the time, but you can cancel]

> The systemd shutdown(8) man page has a -c option for canceling a pending
> shutdown.  I have not tested this.

Thanks :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to check for scheduled shutdown

[Greg Wooledge]

On Tue, Nov 22, 2022 at 06:22:57PM +0100, to...@tuxteam.de wrote:
> Hm. With SysV, you can't either (spoiler alert: the shutdown process
> itself is the one doing the timing by sleeping until fulfillment of
> its task). But you always can cancel it (shutdown -c with SysV, dunno,
> again, with systemd).

The systemd shutdown(8) man page has a -c option for canceling a pending
shutdown.  I have not tested this.

Re: How to check for scheduled shutdown

[tomas]

On Tue, Nov 22, 2022 at 09:09:56AM -0600, David Wright wrote:
> On Tue 22 Nov 2022 at 15:56:48 (+0100), to...@tuxteam.de wrote:
> > On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:
> > 
> > [...]
> > 
> > > There's a file, "scheduled", that's created in /run/systemd/shutdown,
> > > which contains the time, noisiness and destiny of the shutdown.
> > > I haven't tried editing, say, the noisiness, to see whether I can stop
> > > the flow of Wall messages on all my xterms.
> > 
> > *My* shutdown has a command line option (-Q) for the latter. Dunno about
> > yours ;-)
> 
> # shutdown -Q +15
> shutdown: invalid option -- 'Q'
> # 

Ah, that Other Init System. Moving fast and breaking things ;-)

> But I meant in arrears, hence the "say".

I see.

Hm. With SysV, you can't either (spoiler alert: the shutdown process
itself is the one doing the timing by sleeping until fulfillment of
its task). But you always can cancel it (shutdown -c with SysV, dunno,
again, with systemd).

> I still haven't tried editing, say, the MODE=poweroff to MODE=reboot,
> in order to see whether the file is only written, or read at intervals
> as well. I might have done if I hadn't already started my browser, and
> other miscellaneous tasks.

That would be a nice experiment, yes :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to check for scheduled shutdown

[Charles Curley]

On Tue, 22 Nov 2022 09:09:56 -0600
David Wright  wrote:

> > > I haven't tried editing, say, the noisiness, to see whether I can
> > > stop the flow of Wall messages on all my xterms.  
> > 
> > *My* shutdown has a command line option (-Q) for the latter. Dunno
> > about yours ;-)  
> 
> # shutdown -Q +15
> shutdown: invalid option -- 'Q'
> # 

According to the man page for shutdown, --no-wall should do that.


   --no-wall
   Do not send wall message before halt, power-off, reboot.



-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: How to check for scheduled shutdown

[David Wright]

On Tue 22 Nov 2022 at 15:56:48 (+0100), to...@tuxteam.de wrote:
> On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:
> 
> [...]
> 
> > There's a file, "scheduled", that's created in /run/systemd/shutdown,
> > which contains the time, noisiness and destiny of the shutdown.
> > I haven't tried editing, say, the noisiness, to see whether I can stop
> > the flow of Wall messages on all my xterms.
> 
> *My* shutdown has a command line option (-Q) for the latter. Dunno about
> yours ;-)

# shutdown -Q +15
shutdown: invalid option -- 'Q'
# 

But I meant in arrears, hence the "say".

I still haven't tried editing, say, the MODE=poweroff to MODE=reboot,
in order to see whether the file is only written, or read at intervals
as well. I might have done if I hadn't already started my browser, and
other miscellaneous tasks.

Cheers,
David.

Re: How to check for scheduled shutdown

[tomas]

On Tue, Nov 22, 2022 at 08:48:25AM -0600, David Wright wrote:

[...]

> There's a file, "scheduled", that's created in /run/systemd/shutdown,
> which contains the time, noisiness and destiny of the shutdown.
> I haven't tried editing, say, the noisiness, to see whether I can stop
> the flow of Wall messages on all my xterms.

*My* shutdown has a command line option (-Q) for the latter. Dunno about
yours ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How to check for scheduled shutdown

[David Wright]

On Tue 22 Nov 2022 at 13:23:14 (+0100), Urs Thuermann wrote:
> After shutdown -h  I see no way to see this scheduled shutdown.
> Before systemd, I could always see the shutdown process with its
> arguments using ps(1).
> 
> Now, the call to shutdown returns to the shell immediately leaving no
> process.  It probably communicates to the init process 1, but, as
> usual for systemd, very little or nothing seems to be documented.  Or
> at least it's hidden, so that you cannot find it in reasonable time.
> 
> I couldn't find any relevant differences with and without a scheduled
> shutdown in the output of systemctl status --all and systemctl show --all.

There's a file, "scheduled", that's created in /run/systemd/shutdown,
which contains the time, noisiness and destiny of the shutdown.
I haven't tried editing, say, the noisiness, to see whether I can stop
the flow of Wall messages on all my xterms.

Cheers,
David.

How to check for scheduled shutdown

[Urs Thuermann]

After shutdown -h  I see no way to see this scheduled shutdown.
Before systemd, I could always see the shutdown process with its
arguments using ps(1).

Now, the call to shutdown returns to the shell immediately leaving no
process.  It probably communicates to the init process 1, but, as
usual for systemd, very little or nothing seems to be documented.  Or
at least it's hidden, so that you cannot find it in reasonable time.

I couldn't find any relevant differences with and without a scheduled
shutdown in the output of systemctl status --all and systemctl show --all.

urs

Re: stopping job before shutdown.

[mick crane]

On 2022-06-29 18:32, Dan Ritter wrote:

to...@tuxteam.de wrote:

On Wed, Jun 29, 2022 at 09:08:59AM -0400, gene heskett wrote:
> On 6/29/22 08:35, mick crane wrote:
> > hello,
> > Because I don't trust that I've set up power saving properly with PC and
> > monitor if leaving desk I turn off PC with power button on front.
> > It usually is very quick and to start up again.
> > There is printer attached to other PC.
> > Recent update of bookworm when turning off PC with power button there is
> > the message,
> > " stopping job, make Cups quicker for external" or something like that.
> > and it takes 1 minute 30 seconds to stop that and start shutdown.
> > What could be causing that ?
> >
> > mick
> >
> That method of stopping the pc is quite dangerous to the hard drive, you
> may kill the power while the journal is updating the drives contents,
[...]

I took that to mean that the button triggers an orderly
shutdown (otherwise the PC wouldn't get a chance to output
a message).


Yes. Mick's problem is systemd's default timeout.


whatever it was must have been doing it during idle time as it seems to 
have stopped doing it now.


mick

Re: stopping job before shutdown.

[David Wright]

On Wed 29 Jun 2022 at 20:49:40 (+0200), to...@tuxteam.de wrote:
> On Wed, Jun 29, 2022 at 08:42:44PM +0200, Thomas Schmitt wrote:
> > Will Mengarini wrote:
> > > I feel old.
> > > http://www.catb.org/jargon/html/B/Big-Red-Switch.html
> > 
> > Me too. This button pressing for shutdown frightens me.
> > Two years ago i had to craft a molly-guard for the on-off-button
> > on top of this box:
> >   
> > https://static3.caseking.de/media/image/thumbnail/geph-004_geph_004_05_800x800.jpg
> > 
> > I cut a small piece from the transparent lid of a CD case and rasped
> > it to have elegantly rounded corners. A stripe of transparent tape
> > serves as hinge. It's not obscuring the blueish light ring around the
> > button and the disk activity LED in the little hole but still highly
> > safe against human error.
> 
> Nice :-)

My problem was the opposite on this laptop (Dell D430):

https://www.notebookcheck.net/fileadmin/_migrated/pics/rechts_wlan_offen.jpg

If anything touched that button, it would boot up while, say,
closed, padded, and packed in a rucsac. And it ran very hot at
the best of times.

> You could teach your operating system to ignore the ACPI event, then
> you'd have to lean on the button for three interminable seconds to
> havoc your file system (although file systems tend to take hard
> shutdowns without too much fuss these days, ah, they don't build
> things like they used to ;-)

What I would have liked is a default Grub entry that just shutdown
again if no key was pressed (which couldn't happen of course while
the laptop was closed up).

> > Note that the manufacturer took care to armor the USB sockets and the
> > Reset button by a sturdy hatch.

Ah, I haven't seen a reset button for twenty years. The first thing
I used to do whenever I acquired a PC was to disconnect its little
reset cable from the connector on the motherboard.

Cheers,
David.

Re: stopping job before shutdown.

[gene heskett]

On 6/29/22 13:43, Will Mengarini wrote:

* mick crane  [22-06/29=We 13:31 +0100]:

[...] when turning off PC with power button
there is the message, "stopping job" [...]

* gene heskett  [22-06/29=We 09:08 -0400]:

That method of stopping the pc is quite dangerous [...]

* to...@tuxteam.de  [22-06/29=We 16:46 +0200]:

[...] the button triggers an orderly shutdown (otherwise
the PC wouldn't get a chance to output a message) [...]

I feel old.

Go right ahead, or is that behind me? I'm 87, down to one eye
as I just had laser surgery on the other. One of the hazards of
the ultimate revenge, outliving all your enemies. :)


http://www.catb.org/jargon/html/B/Big-Red-Switch.html

.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: stopping job before shutdown.

[tomas]

On Wed, Jun 29, 2022 at 08:42:44PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Will Mengarini wrote:
> > I feel old.
> > http://www.catb.org/jargon/html/B/Big-Red-Switch.html
> 
> Me too. This button pressing for shutdown frightens me.
> Two years ago i had to craft a molly-guard for the on-off-button
> on top of this box:
>   
> https://static3.caseking.de/media/image/thumbnail/geph-004_geph_004_05_800x800.jpg
> 
> I cut a small piece from the transparent lid of a CD case and rasped
> it to have elegantly rounded corners. A stripe of transparent tape
> serves as hinge. It's not obscuring the blueish light ring around the
> button and the disk activity LED in the little hole but still highly
> safe against human error.

Nice :-)

You could teach your operating system to ignore the ACPI event, then
you'd have to lean on the button for three interminable seconds to
havoc your file system (although file systems tend to take hard
shutdowns without too much fuss these days, ah, they don't build
things like they used to ;-)

Cheers
-- 
t
> 


signature.asc
Description: PGP signature

Re: stopping job before shutdown.

[Thomas Schmitt]

Hi,

Will Mengarini wrote:
> I feel old.
> http://www.catb.org/jargon/html/B/Big-Red-Switch.html

Me too. This button pressing for shutdown frightens me.
Two years ago i had to craft a molly-guard for the on-off-button
on top of this box:
  
https://static3.caseking.de/media/image/thumbnail/geph-004_geph_004_05_800x800.jpg

I cut a small piece from the transparent lid of a CD case and rasped
it to have elegantly rounded corners. A stripe of transparent tape
serves as hinge. It's not obscuring the blueish light ring around the
button and the disk activity LED in the little hole but still highly
safe against human error.

Note that the manufacturer took care to armor the USB sockets and the
Reset button by a sturdy hatch.


Have a nice day :)

Thomas

Re: stopping job before shutdown.

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Wed, Jun 29, 2022 at 09:08:59AM -0400, gene heskett wrote:
> > On 6/29/22 08:35, mick crane wrote:
> > > hello,
> > > Because I don't trust that I've set up power saving properly with PC and
> > > monitor if leaving desk I turn off PC with power button on front.
> > > It usually is very quick and to start up again.
> > > There is printer attached to other PC.
> > > Recent update of bookworm when turning off PC with power button there is
> > > the message,
> > > " stopping job, make Cups quicker for external" or something like that.
> > > and it takes 1 minute 30 seconds to stop that and start shutdown.
> > > What could be causing that ?
> > > 
> > > mick
> > > 
> > That method of stopping the pc is quite dangerous to the hard drive, you
> > may kill the power while the journal is updating the drives contents,
> [...]
> 
> I took that to mean that the button triggers an orderly
> shutdown (otherwise the PC wouldn't get a chance to output
> a message).

Yes. Mick's problem is systemd's default timeout.

-dsr-

Re: stopping job before shutdown.

[Will Mengarini]

* mick crane  [22-06/29=We 13:31 +0100]:
>>> [...] when turning off PC with power button
>>> there is the message, "stopping job" [...]

* gene heskett  [22-06/29=We 09:08 -0400]:
>> That method of stopping the pc is quite dangerous [...]

* to...@tuxteam.de  [22-06/29=We 16:46 +0200]:
> [...] the button triggers an orderly shutdown (otherwise
> the PC wouldn't get a chance to output a message) [...]

I feel old.

http://www.catb.org/jargon/html/B/Big-Red-Switch.html

Re: stopping job before shutdown.

[tomas]

On Wed, Jun 29, 2022 at 09:08:59AM -0400, gene heskett wrote:
> On 6/29/22 08:35, mick crane wrote:
> > hello,
> > Because I don't trust that I've set up power saving properly with PC and
> > monitor if leaving desk I turn off PC with power button on front.
> > It usually is very quick and to start up again.
> > There is printer attached to other PC.
> > Recent update of bookworm when turning off PC with power button there is
> > the message,
> > " stopping job, make Cups quicker for external" or something like that.
> > and it takes 1 minute 30 seconds to stop that and start shutdown.
> > What could be causing that ?
> > 
> > mick
> > 
> That method of stopping the pc is quite dangerous to the hard drive, you
> may kill the power while the journal is updating the drives contents,
[...]

I took that to mean that the button triggers an orderly
shutdown (otherwise the PC wouldn't get a chance to output
a message).

I do it all the time with my laptop. Far easier than finding
a terminal to enter "shutdown -h now", or ($DEITY forbid!)
clicking around with a rodent.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: stopping job before shutdown.

[Yvan Masson]

Le 29/06/2022 à 15:08, gene heskett a écrit :

On 6/29/22 08:35, mick crane wrote:

hello,
Because I don't trust that I've set up power saving properly with PC 
and monitor if leaving desk I turn off PC with power button on front.

It usually is very quick and to start up again.
There is printer attached to other PC.
Recent update of bookworm when turning off PC with power button there 
is the message,

" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?

mick


That method of stopping the pc is quite dangerous to the hard drive, you
may kill the power while the journal is updating the drives contents,
wrecking the file system and parking the head on the disk instead of
retracting it to a safe parking position. Don't do it, look in the menu's
for the logout and shutdown and do it in the recommended sequence
which will assure that the drive remains good until something else goes
aglay.

.


Can't tell for this issue, but if I understand properly the OP does 
shutdown is computer properly: by default on Debian, systemd is 
configured so that pressing the power button will shutdown the computer 
properly, see /etc/systemd/logind.conf.


OpenPGP_signature
Description: OpenPGP digital signature

Re: stopping job before shutdown.

[gene heskett]

On 6/29/22 08:35, mick crane wrote:

hello,
Because I don't trust that I've set up power saving properly with PC 
and monitor if leaving desk I turn off PC with power button on front.

It usually is very quick and to start up again.
There is printer attached to other PC.
Recent update of bookworm when turning off PC with power button there 
is the message,

" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?

mick


That method of stopping the pc is quite dangerous to the hard drive, you
may kill the power while the journal is updating the drives contents,
wrecking the file system and parking the head on the disk instead of
retracting it to a safe parking position. Don't do it, look in the menu's
for the logout and shutdown and do it in the recommended sequence
which will assure that the drive remains good until something else goes
aglay.

.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

stopping job before shutdown.

[mick crane]

hello,
Because I don't trust that I've set up power saving properly with PC and 
monitor if leaving desk I turn off PC with power button on front.

It usually is very quick and to start up again.
There is printer attached to other PC.
Recent update of bookworm when turning off PC with power button there is 
the message,

" stopping job, make Cups quicker for external" or something like that.
and it takes 1 minute 30 seconds to stop that and start shutdown.
What could be causing that ?

mick

Re: Stalled system shutdown

[José Luis González]

On Sat, 12 Feb 2022 19:13:28 -0600
Flacusbigotis  wrote:

> > I wonder if the package ntopng is necessary for something.
> 
> See manpage gor ntopng it's for monitoring network resources/activity.
> 
> So if you aren't interested in doing that  then you don't need it installed.

Yes, I have removed it.

Thanks all for your help.

Re: Stalled system shutdown

[Flacusbigotis]

> I wonder if the package ntopng is necessary for something.

See manpage gor ntopng it's for monitoring network resources/activity.

So if you aren't interested in doing that  then you don't need it installed.

Re: Stalled system shutdown

[Andrei POPESCU]

On Vi, 11 feb 22, 13:36:09, José Luis González wrote:
> 
> I wonder if the package ntopng is necessary for something. If I remove
> it nothing else complains. I didn't know this package before.

At least on buster/arm64 nothing depends on it.

Was the package manually installed or does the description ring any 
bells?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Stalled system shutdown

[José Luis González]

On Thu, 10 Feb 2022 21:03:14 -0600
Flacusbigotis  wrote:

> Just a question to help you start troubleshooting:
> 
> Does the shutdown finish quickly/quicker if you first stop the ntopng
> systemd service manually before doing the full shutdown?

I did a "# service status ntopng" and it seems the daemon is dead and
it has errors:

===

• ntopng.service - ntopng - High-Speed Web-based Traffic Analysis and Flow 
Collection Tool
 Loaded: loaded (/lib/systemd/system/ntopng.service; enabled; vendor 
preset: enabled)
 Active: inactive (dead) since Fri 2022-02-11 11:24:19 CET; 2h 3min ago
   Docs: man:ntopng(8)
 file:/usr/share/doc/ntopng/README.Debian
 file:/usr/share/doc/ntopng/UserGuide.pdf.gz
Process: 698 ExecStart=/usr/sbin/ntopng /etc/ntopng.conf (code=exited, 
status=0/SUCCESS)
CPU: 22ms

feb 11 11:24:19 tierra systemd[1]: Starting ntopng - High-Speed Web-based 
Traffic Analysis and Flow Collection Tool...
feb 11 11:24:19 tierra ntopng[698]: 11/Feb/2022 11:24:19 [Ntop.cpp:1902] 
Setting local networks to 127.0.0.0/8
feb 11 11:24:19 tierra ntopng[698]: 11/Feb/2022 11:24:19 [Redis.cpp:111] ERROR: 
ntopng requires redis server to be up and running
feb 11 11:24:19 tierra ntopng[698]: 11/Feb/2022 11:24:19 [Redis.cpp:112] ERROR: 
Please start it and try again or use -r
feb 11 11:24:19 tierra ntopng[698]: 11/Feb/2022 11:24:19 [Redis.cpp:113] ERROR: 
to specify a redis server other than the default
feb 11 11:24:19 tierra ntopng[698]: [Redis.cpp:111] ERROR: ntopng requires 
redis server to be up and running
feb 11 11:24:19 tierra ntopng[698]: [Redis.cpp:112] ERROR: Please start it and 
try again or use -r
feb 11 11:24:19 tierra ntopng[698]: [Redis.cpp:113] ERROR: to specify a redis 
server other than the default
feb 11 11:24:19 tierra systemd[1]: ntopng.service: Succeeded.
feb 11 11:24:19 tierra systemd[1]: Started ntopng - High-Speed Web-based 
Traffic Analysis and Flow Collection Tool.

===

I wonder if the package ntopng is necessary for something. If I remove
it nothing else complains. I didn't know this package before.

By the way, with ntopng uninstalled my system shuts down normally.

Thanks for your help.


> On Thu, Feb 10, 2022, 5:59 PM José Luis González  wrote:
> 
> > Hi,
> >
> > When shutting down, after upgrading to Debian 11, system shutdown hangs
> > (freezes) for some time (about 1-2 minutes) anytime, making it
> > bothersome to shut the system down.
> >
> > The freeze happens afther the "Stopped target remote filesystems"
> > status line. After a while "A stop job is running for ntopng" is
> > printed with an "in progress" status in red and a timeout of 1 minute
> > 30 seconds, which is exhausted. So everyt time I shut down I get a 1
> > minute and 30 seconds delay.
> >
> > Anyone can help, please?
> >
> >

Re: Stalled system shutdown

[Cindy Sue Causey]

On 2/11/22, Tixy  wrote:
> On Fri, 2022-02-11 at 00:58 +0100, José Luis González wrote:
>> Hi,
>>
>> When shutting down, after upgrading to Debian 11, system shutdown hangs
>> (freezes) for some time (about 1-2 minutes) anytime, making it
>> bothersome to shut the system down.
>>
>> The freeze happens afther the "Stopped target remote filesystems"
>> status line. After a while "A stop job is running for ntopng" is
>> printed with an "in progress" status in red and a timeout of 1 minute
>> 30 seconds, which is exhausted. So everyt time I shut down I get a 1
>> minute and 30 seconds delay.
>>
>> Anyone can help, please?
>
> Do you have any network filesystems mounted? I've found that systemd
> takes down the network connections before it unmounts disks, so if I
> forget to unmount them before shutting down I get this delay.


Mine hangs because it's shutting down Firefox (Nightly from their
website these days).

Just as example, if I log out then log back in and run "ps aux|grep
firefox" after logouts that take a long time, there will most likely
be a long list of associated PIDs still in operation. If I try to
launch Firefox at that moment, it will most likely fail with an
advisement that a Firefox instance is already running. If I wait a few
more seconds then try again, Firefox will FINALLY have shut down the
rest of the way.

It's been ages since I first realized that was occurring. It was an
eye opener into that there's still a lot to learn about how operating
systems and their packages work under the hood. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: Stalled system shutdown

[Tixy]

On Fri, 2022-02-11 at 00:58 +0100, José Luis González wrote:
> Hi,
> 
> When shutting down, after upgrading to Debian 11, system shutdown hangs
> (freezes) for some time (about 1-2 minutes) anytime, making it
> bothersome to shut the system down.
> 
> The freeze happens afther the "Stopped target remote filesystems"
> status line. After a while "A stop job is running for ntopng" is
> printed with an "in progress" status in red and a timeout of 1 minute
> 30 seconds, which is exhausted. So everyt time I shut down I get a 1
> minute and 30 seconds delay.
> 
> Anyone can help, please?

Do you have any network filesystems mounted? I've found that systemd
takes down the network connections before it unmounts disks, so if I
forget to unmount them before shutting down I get this delay.

-- 
Tixy

Re: Stalled system shutdown

[Flacusbigotis]

Just a question to help you start troubleshooting:

Does the shutdown finish quickly/quicker if you first stop the ntopng
systemd service manually before doing the full shutdown?

On Thu, Feb 10, 2022, 5:59 PM José Luis González  wrote:

> Hi,
>
> When shutting down, after upgrading to Debian 11, system shutdown hangs
> (freezes) for some time (about 1-2 minutes) anytime, making it
> bothersome to shut the system down.
>
> The freeze happens afther the "Stopped target remote filesystems"
> status line. After a while "A stop job is running for ntopng" is
> printed with an "in progress" status in red and a timeout of 1 minute
> 30 seconds, which is exhausted. So everyt time I shut down I get a 1
> minute and 30 seconds delay.
>
> Anyone can help, please?
>
>

Stalled system shutdown

[José Luis González]

Hi,

When shutting down, after upgrading to Debian 11, system shutdown hangs
(freezes) for some time (about 1-2 minutes) anytime, making it
bothersome to shut the system down.

The freeze happens afther the "Stopped target remote filesystems"
status line. After a while "A stop job is running for ntopng" is
printed with an "in progress" status in red and a timeout of 1 minute
30 seconds, which is exhausted. So everyt time I shut down I get a 1
minute and 30 seconds delay.

Anyone can help, please?

Re: Service stuck at shutdown

[Erwan David]

Le 11/11/2021 à 17:55, Erwan David a écrit :

Le 11/11/2021 à 06:16, David Wright a écrit :

A workaround that might shorten the wait, but only if you're confident
that there aren't processes that need that long to complete, is to edit
the line   DefaultTimeoutStopSec=90s   in /etc/systemd/system.conf to
something smaller.

Cheers,
David.




I do not know : I was not even aware that kde was using dconf.

From what I could see, it seems that kded5 starts dconf-service at end 
of session, I presume to save some settings (but which one s ?) and 
something fails


would it help to remove the ~/.config/dconf/user file when kde is not 
running ? The /etc/dconf/db directory is empty.


I do not understand what dconf-editor shows me.


Sould I file a bug report to dconf-service or kded5 ?




I tried removung the file, works once, but nort more. since 
deconf-service(1) says it is crash proof I added an override to 
dconf.service unit :


TimeoutStopFailureMode=kill
TimeoutStopSec=10s

Re: Service stuck at shutdown

[Erwan David]

Le 11/11/2021 à 06:16, David Wright a écrit :

On Wed 10 Nov 2021 at 22:18:07 (+0100), Erwan David wrote:

Le 10/11/2021 à 20:01, Tixy a écrit :

On Wed, 2021-11-10 at 18:33 +0100, Erwan David wrote:

Since some time, I always have to wait 1 min 30 at shut down because
some service does not stop (for user erwan is said).

How can I debug this, know which service is blocking the shutdown ?

Assuming you system is using systemd then look at the logs for the last
boot with:

#journalctl -b-1

and scroll to the end where you will see what was going on during
shutdown. Errors will likely be highlighted in red (they are for me).

The times I've had hanging during shutdown is due to the network being
shut down before network filesystems are unmounted.


Thanks, for me the culprint is 'dconf worker' (I see it being killed
with a 'timeout error') about 90s after preceding message.

I do not know where it comes from, I have dconf-service installed as a
dependency of many things, thus it is not removable. However I do not
find any messages about dconf, and what does not work correctly.

SO now the question is wtf is dconf doing, and how to
correct it (and no I have no idea of how dconf works, and even what
problem it is intended to solve.

A workaround that might shorten the wait, but only if you're confident
that there aren't processes that need that long to complete, is to edit
the line   DefaultTimeoutStopSec=90s   in /etc/systemd/system.conf to
something smaller.

Cheers,
David.




I do not know : I was not even aware that kde was using dconf.

From what I could see, it seems that kded5 starts dconf-service at end 
of session, I presume to save some settings (but which one s ?) and 
something fails


would it help to remove the ~/.config/dconf/user file when kde is not 
running ? The /etc/dconf/db directory is empty.


I do not understand what dconf-editor shows me.


SHould I file a bug report to dconf-service or kded5 ?

Re: Service stuck at shutdown

[David Wright]

On Wed 10 Nov 2021 at 22:18:07 (+0100), Erwan David wrote:
> Le 10/11/2021 à 20:01, Tixy a écrit :
> > On Wed, 2021-11-10 at 18:33 +0100, Erwan David wrote:
> > > Since some time, I always have to wait 1 min 30 at shut down because
> > > some service does not stop (for user erwan is said).
> > > 
> > > How can I debug this, know which service is blocking the shutdown ?
> > Assuming you system is using systemd then look at the logs for the last
> > boot with:
> > 
> > #journalctl -b-1
> > 
> > and scroll to the end where you will see what was going on during
> > shutdown. Errors will likely be highlighted in red (they are for me).
> > 
> > The times I've had hanging during shutdown is due to the network being
> > shut down before network filesystems are unmounted.
> > 
> Thanks, for me the culprint is 'dconf worker' (I see it being killed
> with a 'timeout error') about 90s after preceding message.
> 
> I do not know where it comes from, I have dconf-service installed as a
> dependency of many things, thus it is not removable. However I do not
> find any messages about dconf, and what does not work correctly.
> 
> SO now the question is wtf is dconf doing, and how to
> correct it (and no I have no idea of how dconf works, and even what
> problem it is intended to solve.

A workaround that might shorten the wait, but only if you're confident
that there aren't processes that need that long to complete, is to edit
the line   DefaultTimeoutStopSec=90s   in /etc/systemd/system.conf to
something smaller.

Cheers,
David.

Re: my pc is shutdown unexpectedly

[Michael Stone]

On Thu, Sep 10, 2020 at 12:15:56PM +, Long Wind wrote:

3rd installation failure is probably not caused by  problem disk
but 1st and 2nd installation failure is


Almost certainly not. Turning off *is not* a symptom of a bad disk. You 
have at least a cooling issue, and who knows what other problems. Your 
symptoms correlate much better with that than with a hard drive problem.

Re: my pc is shutdown unexpectedly

[Michael Stone]

On Thu, Sep 10, 2020 at 12:36:21PM +, Long Wind wrote:

i've been warned  "Core temperature above threshold" for a long time
i just ignore it.  probably it isn't cause of shutdown
if it is, it can warn explicitly in /var/log that it will shutdown
surely it can beep before shutdown, but i didn't hear any beep


The system can turn itself off regardless of the OS, and that is 
something that systems do if they overheat. 

Re: my pc is shutdown unexpectedly

[Long Wind]

 i've been warned  "Core temperature above threshold" for a long timei just 
ignore it.  probably it isn't cause of shutdownif it is, it can warn explicitly 
in /var/log that it will shutdownsurely it can beep before shutdown, but i 
didn't hear any beep

it shutdown unexpectedly, it means answer can't be found by studying /var/log??

  
 

Re: my pc is shutdown unexpectedly

[Long Wind]

 

On Thursday, September 10, 2020, 8:03:16 AM EDT, Michael Stone 
 wrote:  
 
 
there was never anything reported that sounded remotely like a hard disk 
problem.

3rd installation failure is probably not caused by  problem diskbut 1st and 2nd 
installation failure is 
the pc is stable, it can run linux, it never show any sign that i can't explain 


  

Re: my pc is shutdown unexpectedly

[Michael Stone]

On Thu, Sep 10, 2020 at 12:03:22PM +0200, Marco Möller wrote:
After you recently already have had difficult to explain problems with 
a hard disk, 


there was never anything reported that sounded remotely like a hard disk 
problem.

Re: my pc is shutdown unexpectedly

[Marco Möller]

On 10.09.20 11:16, Long Wind wrote:



On Thursday, September 10, 2020, 1:22:36 AM EDT, Felix Miata 
 wrote:



Have you cleaned the inside of the PC? Is dust clogging cooling fins or 
fans or
case vents? Are fans spinning? PSUs can overheat and cause breakdown as 
well.


i don't have such skill as pc maintenance. i have removed heat sink but 
unable to install back. before that i have tested memory with 
memtest86+, it quickly shutdown. i think it's not memory's fault, if it 
is memtest86+ shall report error in red.




Of course your hardware needs all fans clean and also the thermal 
conduction between CPU and heat sink in proper shape (thermal paste not 
dry and still in good condition).


After you recently already have had difficult to explain problems with a 
hard disk, did you finally check the motherboard, RAM and CPU to still 
perform reliable, as recommended in the thread for your hard disk 
problem? You will remember, I recommended to confirm if your hardware 
runs stable under a high load for a long time. The test tools 
recommended to use are:

  RAM: memtest86+ (accessible as an boot option from rescue distros)
  CPU: stress-ng (package in the Debian repository)
  Motherboard: dd (package coreutils, should already be installed)

Good Luck! Marco.

Re: my pc is shutdown unexpectedly

[Long Wind]

 

On Thursday, September 10, 2020, 1:22:36 AM EDT, Felix Miata 
 wrote: 

Have you cleaned the inside of the PC? Is dust clogging cooling fins or fans or
case vents? Are fans spinning? PSUs can overheat and cause breakdown as well.

i don't have such skill as pc maintenance. i have removed heat sink but unable 
to install back. before that i have tested memory with memtest86+, it quickly 
shutdown. i think it's not memory's fault, if it is memtest86+ shall report 
error in red.

  

Re: my pc is shutdown unexpectedly

[Felix Miata]

Long Wind composed on 2020-09-10 04:52 (UTC):

> possible cause : cpu too hot?
> Sep 10 00:00:54 debian kernel: [ 9858.515989] CPU0: Core temperature/speed 
> normal
> Sep 10 00:15:46 debian kernel: [10751.125312] CPU0: Core temperature/speed 
> normal
> Sep 10 00:20:50 debian kernel: [11054.410233] CPU0: Core temperature above 
> threshold, cpu clock throttled (total events = 395)
> Sep 10 00:20:50 debian kernel: [11054.45] CPU0: Core temperature/speed 
> normal
> Sep 10 00:25:59 debian kernel: [11364.057595] CPU0: Core temperature above 
> threshold, cpu clock throttled (total events = 494)
> Sep 10 00:26:00 debian kernel: [11364.837948] perf: interrupt took too long 
> (10314 > 10277), lowering kernel.perf_event_max_sample_rate to 19250

Have you cleaned the inside of the PC? Is dust clogging cooling fins or fans or
case vents? Are fans spinning? PSUs can overheat and cause breakdown as well.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: lxde + ligthdm Shutdown

[Andrei POPESCU]

On Ma, 14 iul 20, 12:04:51, basti wrote:
> Hello, when i try to shutdown from my lxde session i get:|
> 
> GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired:
> Interactive authentication required.

Hmm, this worked for me out of the box. Is your user a member of 'sudo'?

As far as I recall various other applications have (ab)used this to mean 
'this user is generally allowed to do more advanced stuff' (like 
shutting down the system).

If this doesn't help please provide any other information that might be 
relevant, in particular any customizations you did compared to a default 
LXDE install (no systemd, no Recommends, etc.).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

lxde + ligthdm Shutdown

[basti]

Hello, when i try to shutdown from my lxde session i get:|

GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired:
Interactive authentication required.

When i frist logout then I can Shutdown from ligthdm.

OS: Debian Buster

Best Regards
|

Re: HP Device Manager loses network printer on shutdown

[Brad Rogers]

On Mon, 18 May 2020 11:24:17 +0200
Frank Weißer  wrote:

Hello Frank,

>Everytime I start my workstation (DebianEdu 9) I have to re-run setup
>of the HP Device Manager , because the LaserJet Pro 200 color,
>connected via network, is lost. The setup routine dousn't need to
>connect to hp again, as id did at the first installation of the printer.

Difficult to be sure without additional info:

  Does the printer have a static IP assigned to it?
  Do you turn the printer off?

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Does she always shout at you, does she tell you what to do
Family Life - Sham 69


pgpJVRKIMLx4H.pgp
Description: OpenPGP digital signature

HP Device Manager loses network printer on shutdown

[Frank Weißer]

Hi!

Everytime I start my workstation (DebianEdu 9) I have to re-run setup of 
the HP Device Manager , because the LaserJet Pro 200 color, connected 
via network, is lost. The setup routine dousn't need to connect to hp 
again, as id did at the first installation of the printer.


Where do I have to take a look?

Any help appreciated.

readU
Frank

Re: unattended-upgrades does not install upgrades on shutdown

[Charles Curley]

On Tue, 15 Oct 2019 17:03:19 +1100
Keith Bainbridge  wrote:

> Also, there is a process to get one PC to download the updates, and 
> share that  /var/cache/apt/archives/ to your other PCs

You might look into apt-cacher or apt-cacher-ng for that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 14:10, Curt a écrit :

On 2019-10-15, Yvan Masson  wrote:


I am currently using a VM with snapshots to try to find the culprit, I
will let you know.


I could not find the culprit so I reported the bug:
https://github.com/mvo5/unattended-upgrades/issues/229




There's this (not sure if it's your issue or not):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155

  If /var resides on a separate file-system which is unmounted before
  unattended-upgrade-shutdown is run, it may repeatedly (by default for
  10 minutes) try to acquire it's lock-file but fail since the containing
  folder doesn't exist.

For which the fix is a file
  
  /etc/systemd/system/unattended-upgrades.service.d/mounts.conf


containing

  [Unit]
  RequiresMountsFor=/var/log

Maybe irrelevant. Or not.

A bientôt,

C.

Thanks for the hint, but I have everything in one partition, 
unattended-upgrades stops just after detecting which upgrades are 
available, after 1 or 2 minutes.


Yvan

Re: unattended-upgrades does not install upgrades on shutdown

[Curt]

On 2019-10-15, Yvan Masson  wrote:
>> 
>> I am currently using a VM with snapshots to try to find the culprit, I 
>> will let you know.
>
> I could not find the culprit so I reported the bug:
> https://github.com/mvo5/unattended-upgrades/issues/229
>>>

There's this (not sure if it's your issue or not):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155

 If /var resides on a separate file-system which is unmounted before
 unattended-upgrade-shutdown is run, it may repeatedly (by default for
 10 minutes) try to acquire it's lock-file but fail since the containing
 folder doesn't exist.

For which the fix is a file
 
 /etc/systemd/system/unattended-upgrades.service.d/mounts.conf

containing

 [Unit]
 RequiresMountsFor=/var/log

Maybe irrelevant. Or not. 

A bientôt,

C.

-- 
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 09:19, Yvan Masson a écrit :

Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.


I believe the timeout in this case is never reached: computer goes off 
after 1 or 2 minutes, just the time for unattended-upgrades to calculate 
what should be upgraded. Also, unattended-upgrades download packages 
before the computer shuts down.


I am currently using a VM with snapshots to try to find the culprit, I 
will let you know.


I could not find the culprit so I reported the bug:
https://github.com/mvo5/unattended-upgrades/issues/229


Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



This would be great, because bandwidth is very slow in this school. What
solution do you think of? Something like apt-cacher-ng on one host?

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.


I believe the timeout in this case is never reached: computer goes off 
after 1 or 2 minutes, just the time for unattended-upgrades to calculate 
what should be upgraded. Also, unattended-upgrades download packages 
before the computer shuts down.


I am currently using a VM with snapshots to try to find the culprit, I 
will let you know.


Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



This would be great, because bandwidth is very slow in this school. What
solution do you think of? Something like apt-cacher-ng on one host?

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.

Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Charles Curley]

On Tue, 15 Oct 2019 11:31:22 +1100
Keith Bainbridge  wrote:

> It was intuition rather than any knowledge I had - beyond the fact
> that sometimes upgrade takes longer than normal.
> 
> How to prevent a repeat is the real question.

Upgrades and updates often require fetching across the network, which
can induce network delays. For other reasons entirely, I prefetch my
upgrades so they are on the computer before I start the upgrades. I put
the following into a file in /etc/cron.d:


# cron replaces the percent sign with a new line, so we escape it with a back 
slash.
   5  3  ** *   rootsleep $( echo $((1 + 
RANDOM \% 1200)) ) ; /usr/bin/apt-get update > /dev/null && /usr/bin/apt-get 
-dy dist-upgrade > /dev/null

(Pasted with long lines; your mail client may mangle it.)

You might do something similar before the automatic upgrades occur.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 14/10/19 7:42 pm, Yvan Masson wrote:


You were right Keith: after applying some updates manually, remaining 
updates are
properly installed with unattended-upgrade… Now I need to understand 
what was

blocking.



It was intuition rather than any knowledge I had - beyond the fact that 
sometimes upgrade takes longer than normal.


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??


--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 14/10/2019 à 04:22, Keith Bainbridge a écrit :

On 14/10/19 6:16 am, Yvan Masson wrote:

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade 
automatically on shutdown via unattended-upgrades. I am almost sure 
it worked at first but it does not anymore. I would really appreciate 
any suggestion as I already spent a few hours on this issue without 
any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been 
modified):

 Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
 };
 Unattended-Upgrade::MinimalSteps "false";
 Unattended-Upgrade::InstallOnShutdown "true";
 Unattended-Upgrade::Verbose "true";
 Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
 APT::Periodic::Unattended-Upgrade "1";
 APT::Periodic::Update-Package-Lists "1";
 APT::Periodic::Download-Upgradeable-Packages "1";
 APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have 
already been downloaded. Where could be my mistake? Could this be a 
bug of the script when too many packages are upgradable (because yes 
it has worked at the very beginning)?


Best regards,
Yvan









Perhaps there was a larger than normal upgrade to exceeded to 10mins 
delay, and it's all stalled



Suggest a manual upgrade to see what results you get.

You were right Keith: after applying some updates manually, remaining 
updates are
properly installed with unattended-upgrade… Now I need to understand 
what was

blocking.

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 14/10/19 6:16 am, Yvan Masson wrote:

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at 
first but it does not anymore. I would really appreciate any 
suggestion as I already spent a few hours on this issue without any 
result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been 
modified):

 Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
 };
 Unattended-Upgrade::MinimalSteps "false";
 Unattended-Upgrade::InstallOnShutdown "true";
 Unattended-Upgrade::Verbose "true";
 Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
 APT::Periodic::Unattended-Upgrade "1";
 APT::Periodic::Update-Package-Lists "1";
 APT::Periodic::Download-Upgradeable-Packages "1";
 APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have 
already been downloaded. Where could be my mistake? Could this be a 
bug of the script when too many packages are upgradable (because yes 
it has worked at the very beginning)?


Best regards,
Yvan









Perhaps there was a larger than normal upgrade to exceeded to 10mins 
delay, and it's all stalled



Suggest a manual upgrade to see what results you get.


--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at first 
but it does not anymore. I would really appreciate any suggestion as I 
already spent a few hours on this issue without any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been modified):

     Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
     };
     Unattended-Upgrade::MinimalSteps "false";
     Unattended-Upgrade::InstallOnShutdown "true";
     Unattended-Upgrade::Verbose "true";
     Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
     APT::Periodic::Unattended-Upgrade "1";
     APT::Periodic::Update-Package-Lists "1";
     APT::Periodic::Download-Upgradeable-Packages "1";
     APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have already 
been downloaded. Where could be my mistake? Could this be a bug of the 
script when too many packages are upgradable (because yes it has worked 
at the very beginning)?


Best regards,
Yvan

unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at first 
but it does not anymore. I would really appreciate any suggestion as I 
already spent a few hours on this issue without any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been modified):

Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=buster-updates";
  "origin=Debian,codename=buster,label=Debian";
  "origin=Debian,codename=buster,label=Debian-Security";
};
Unattended-Upgrade::MinimalSteps "false";
Unattended-Upgrade::InstallOnShutdown "true";
Unattended-Upgrade::Verbose "true";
Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have already 
been downloaded. Where could be my mistake? Could this be a bug of the 
script when too many packages are upgradable (because yes it has worked 
at the very beginning)?


Best regards,
Yvan

(solved) Re: Debian 10 freezes upon shutdown, reboot and logout

[Beco]

Short answer:

# apt-get install nvidia-detect

and then you install the driver it recommends after detection.

That is it.



alternative version:

the driver nouveau is broken (for my system). It not only hangs the system
during the tasks on the subject of this email, but also during init 1, init
3, a simple alt+f1 to get a tty, etc. And sometimes doing nothing, just
using the computer (say, gimp, editing an image).

To test without the necessity to change the system and risk a "blank
screen", I went in the BIOS and disabled the nvidia graphic card, letting
only the intel_integrated card running.

The system booted flawlessly, with no nouveau driver. Worked just fine.
Then I just installed nvidia proprietary on top of it, getting nouveau
automatically removed in the process.

A few boots, reboots, shutdowns and logouts after, just to be sure, and
voilà! The system is perfect.

Cheers,

Beco



On Mon, 30 Sep 2019 at 00:31, Beco  wrote:

> Some updates on testing I'm doing:
>
> $ init 1
> also hangs
>
> Booting from grub using init 3 gave me a single chance to reboot without
> hanging, other variables being acpi=off. But somehow I was not able to
> reproduce the behaviour.
>
> Messages appearing on screen when init 3 was running, or in kernel.log:
>
> ---
> TTM Buffer eviction failed
> nouveau DRM failed idle channel 0
> ---
>
>
> Now the messages below appear while the shutting down (or rebooting) is
> running its course, so I have no terminal at hand. Just the notifications
> scrolling:
> (I took a picture with a mobile and wrote them by hand. Forgive any typos
> or abbreviations)
>
> after init 1 or reboot or shutdown actually
>
> INFO: rcu_sched detected stalls on CPUs/tasks:
> rcu: $3-...0: (0 ticks this GP) idle=51a/1/0x4
> rcu: $(detected by 6, t=5252 jiffies, g...)
> NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
> INFO: rcu_sched detected expedited stalls on CPUs/tasks:
> rcu: blocking rcu_node structures:
> watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [systemd:1]
> ...
> repeats in an endless loop
> ...
>
> INFO: task irq/87-ELANO611:556 blocked for more than 120 seconds
> Tainted: GWOEL4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u1
> echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message
> ...
> repeats for other tasks (haveged, systemd-logind, wpa_supplicant,
> dhclient, QQm1Thread, GlobalQueue, gdbus, ...)
> ...
>
>
>
> i2c_transfer+0x51...
> elan_i2c_get_report+0x1c...
> ? __switch_to+0x8c/0x440...
> elan_isr+0x4b...
> ? __schedule+0x2aa...
> ? __wake_up_common_lock+...
> ? irq_finalize_oneshot
> irq_thread_fn+0x1f...
> kthread+0x112
> ret_from_fork+...
> watchdog: BUG: soft lockup...
> Modules linked in: ufs qnx4 hfsplus hfs minix vfat msdos fat jfs xfs
> dm_mod pc sst_ssp snd_hda_ext_core snd_soc_acpi_intel_match
> x86_pkg_temp_thermal btbcm irqbypass videobuf2_vmalloc btintel ideapad_l...
> pcspkr xor btrfs ecb zstd_decompre... xtables autofs4 media pcc_cpufreq...
> CPU: 5 PID:: 1 Comm: systemd Tainted: G
> Hardware name: LENOVO 81G3/LNVNB161216, BIOS 6JCN23WW 01/23/2018
> RIP: 0010:smp_call_function_many+0x1f8/0x250
> Code: c7 e8 6c 3f 5f 00...
> RAX: 0003 RBX: 9e RCX: fff...
> RDX: 0001 RSI:  RDI: fff9e...
> RBP:  R08:  R09:
> R10:...  R11:... R12:...
> R13:... R14: R15:...
> FS:... GS:... knlGS:...
> CS: ... DS: ... ES: ... CRO:
> CR2:  CR3:... CR4:
> Call Trace:
> ? tcp_v6_pre_connect...
> ? add_nops...
> on_each_cpu...
> text_poke_bp
> __jump_label_transform...
> arch_jump_label...
> __jump_label_update...
> __static_key_slow_dec_cpu...
> __cgroup_bpf_detach...
> __cgroup_bpf_prog_detach...
> __x64_sys_bpf...
> do_syscall_64+0x53/0x110
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:
> ...
> repeat, different memory dump
> ...
> Task dump for CPU 3:
> Xorg R running task
> Call Trace:
> ? nvif_object_fini...
> ?nouveaus_vmm_fini
> ?nouveau_cli_fini
> ?nouveau_drm_postcl...
> ?drm_file_free.part
> ?drm_release+...
> ?__fput
> ?task_work_run...
> ?do_exit
> ?handle_mm_fault
> ?do_group_exit
> ?__x64_sys_exit_group...
> do_syscall_64+0x53/0x110
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>
> --
>
>
> I would prefer to read that on logs instead of a mobile picture... Not
> sure yet what logs to look (or maybe turn on)
>
> dmesg shows only the starting process, not the hanging avenue when trying
> to shutdown.
>
> Thanks for any help or tip.
>
> Att.,
> Beco
>
>
>
>
>
>
> On Sun, 29 Sep 2019 at 21:27, Beco  wrote:
>
>>
>> Hi

Re: Sig attribution (Re: Debian 10 freezes upon shutdown, reboot and logout)

[rhkramer]

On Monday, September 30, 2019 07:33:43 AM rhkra...@gmail.com wrote:
> On Sunday, September 29, 2019 11:31:55 PM Beco wrote:
> > > "I know you think you understand what you thought I said but I'm not
> > > sure you realize that what you heard is not what I meant" -- Alan
> > > Greenspan
> 
> Interesting.  I'm almost sure that somebody else said that before Greenspan
> (or something very similar), but I'm not ready to go googling atm.

Ok, I did a *little* googling (well, actually ddg'ing) and found the below, 
but I don't even think that is the earliest use of the phrase (better word -- 
aphorism?) -- when I was very young (well, actually before I was born ;-), I 
remember sayings like this (I mean, sort of humorous sayings) being passed 
around in various ways, including on some commercially printed little cards 
that you could post somewhere (like on your desk, or a bulletin board, or 
such) -- I'm not sure whether this was one of those or not (and my stack of 
those is long gone):

From: 
[[https://www.reddit.com/r/QuotesPorn/comments/40pwgx/i_know_you_think_you_understand_what_you_thought/]]

`
UncleSaddam
2 points ·
3 years ago

I know that you believe you understand what you think I said, but I'm not 
sure you realize that what you heard is not what I meant.

Attributed to Robert McCloskey, U.S. State Department spokesman, by Marvin 
Kalb, CBS reporter, in TV Guide, 31 March 1984, citing an unspecified press 
briefing during the Vietnam war.

Misattributed to Alan Greenspan:

I know you think you understand what you thought I said, but I'm not sure 
you realize that what you heard is not what I meant

Attributed to Greenspan by Rupert Cornwell, "Alan Greenspan: The buck 
starts here", The Independent, 27 April 2003, citing an unspecified Capitol 
Hill hearing.
'

Sig attribution (Re: Debian 10 freezes upon shutdown, reboot and logout)

[rhkramer]

On Sunday, September 29, 2019 11:31:55 PM Beco wrote:
> > "I know you think you understand what you thought I said but I'm not sure
> > you realize that what you heard is not what I meant" -- Alan Greenspan

Interesting.  I'm almost sure that somebody else said that before Greenspan 
(or something very similar), but I'm not ready to go googling atm.

Re: Debian 10 freezes upon shutdown, reboot and logout

[Beco]

Some updates on testing I'm doing:

$ init 1
also hangs

Booting from grub using init 3 gave me a single chance to reboot without
hanging, other variables being acpi=off. But somehow I was not able to
reproduce the behaviour.

Messages appearing on screen when init 3 was running, or in kernel.log:

---
TTM Buffer eviction failed
nouveau DRM failed idle channel 0
---


Now the messages below appear while the shutting down (or rebooting) is
running its course, so I have no terminal at hand. Just the notifications
scrolling:
(I took a picture with a mobile and wrote them by hand. Forgive any typos
or abbreviations)

after init 1 or reboot or shutdown actually

INFO: rcu_sched detected stalls on CPUs/tasks:
rcu: $3-...0: (0 ticks this GP) idle=51a/1/0x4
rcu: $(detected by 6, t=5252 jiffies, g...)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
INFO: rcu_sched detected expedited stalls on CPUs/tasks:
rcu: blocking rcu_node structures:
watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [systemd:1]
...
repeats in an endless loop
...

INFO: task irq/87-ELANO611:556 blocked for more than 120 seconds
Tainted: GWOEL4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u1
echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message
...
repeats for other tasks (haveged, systemd-logind, wpa_supplicant, dhclient,
QQm1Thread, GlobalQueue, gdbus, ...)
...



i2c_transfer+0x51...
elan_i2c_get_report+0x1c...
? __switch_to+0x8c/0x440...
elan_isr+0x4b...
? __schedule+0x2aa...
? __wake_up_common_lock+...
? irq_finalize_oneshot
irq_thread_fn+0x1f...
kthread+0x112
ret_from_fork+...
watchdog: BUG: soft lockup...
Modules linked in: ufs qnx4 hfsplus hfs minix vfat msdos fat jfs xfs dm_mod
pc sst_ssp snd_hda_ext_core snd_soc_acpi_intel_match x86_pkg_temp_thermal
btbcm irqbypass videobuf2_vmalloc btintel ideapad_l... pcspkr xor btrfs ecb
zstd_decompre... xtables autofs4 media pcc_cpufreq...
CPU: 5 PID:: 1 Comm: systemd Tainted: G
Hardware name: LENOVO 81G3/LNVNB161216, BIOS 6JCN23WW 01/23/2018
RIP: 0010:smp_call_function_many+0x1f8/0x250
Code: c7 e8 6c 3f 5f 00...
RAX: 0003 RBX: 9e RCX: fff...
RDX: 0001 RSI:  RDI: fff9e...
RBP:  R08:  R09:
R10:...  R11:... R12:...
R13:... R14: R15:...
FS:... GS:... knlGS:...
CS: ... DS: ... ES: ... CRO:
CR2:  CR3:... CR4:
Call Trace:
? tcp_v6_pre_connect...
? add_nops...
on_each_cpu...
text_poke_bp
__jump_label_transform...
arch_jump_label...
__jump_label_update...
__static_key_slow_dec_cpu...
__cgroup_bpf_detach...
__cgroup_bpf_prog_detach...
__x64_sys_bpf...
do_syscall_64+0x53/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:
...
repeat, different memory dump
...
Task dump for CPU 3:
Xorg R running task
Call Trace:
? nvif_object_fini...
?nouveaus_vmm_fini
?nouveau_cli_fini
?nouveau_drm_postcl...
?drm_file_free.part
?drm_release+...
?__fput
?task_work_run...
?do_exit
?handle_mm_fault
?do_group_exit
?__x64_sys_exit_group...
do_syscall_64+0x53/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9


--


I would prefer to read that on logs instead of a mobile picture... Not sure
yet what logs to look (or maybe turn on)

dmesg shows only the starting process, not the hanging avenue when trying
to shutdown.

Thanks for any help or tip.

Att.,
Beco






On Sun, 29 Sep 2019 at 21:27, Beco  wrote:

>
> Hi,
>
> I'm currently having issues with a LENOVO ideapad320.
>
> Using Stretch was smooth. But this weekend I've updated to Buster and I'm
> having trouble to shutdown the system.
> Rebooting also freezes.
>
> Watchdog says the CPU number #something is 22 seconds froze.
>
> I usually don't use "logout" since it is my personal laptop and I only
> uses KDE, but I've decided to give i3wm a try and because of that I
> discovered that not only shutdown and reboot hangs the system, but also
> logout.
>
> I need to finish shutdown with SysReq commands everytime to sync, umount
> and turn off.
>
> Not sure what logs I need to look, but kern.log shows nouveau driver
> having problems. Not much to go after, but may be a tip.
> Also, I've tried to add ACPI=force to grub, just in case, to test. Nothing
> changed.
>
> A small detail: my var partition is separated from the root. I'm telling
> this because in the old system ever reboot gave me a "unable to umount
> var". But it was ok. When I installed Stretch in 2018 I researched the
> problem and it was only a warning from journal.conf that could be solved by
> using "volatile". Anyway, I even considered to move /var to the root just
> to test, but after reading more about the problem I decided not to pursue
> this way.
>
> It must be something else... Maybe I could try to remove nouveau just to
> test. But since removing and adding nouveau is really hard, and the video
> is worki

Debian 10 freezes upon shutdown, reboot and logout

[Beco]

Hi,

I'm currently having issues with a LENOVO ideapad320.

Using Stretch was smooth. But this weekend I've updated to Buster and I'm
having trouble to shutdown the system.
Rebooting also freezes.

Watchdog says the CPU number #something is 22 seconds froze.

I usually don't use "logout" since it is my personal laptop and I only uses
KDE, but I've decided to give i3wm a try and because of that I discovered
that not only shutdown and reboot hangs the system, but also logout.

I need to finish shutdown with SysReq commands everytime to sync, umount
and turn off.

Not sure what logs I need to look, but kern.log shows nouveau driver having
problems. Not much to go after, but may be a tip.
Also, I've tried to add ACPI=force to grub, just in case, to test. Nothing
changed.

A small detail: my var partition is separated from the root. I'm telling
this because in the old system ever reboot gave me a "unable to umount
var". But it was ok. When I installed Stretch in 2018 I researched the
problem and it was only a warning from journal.conf that could be solved by
using "volatile". Anyway, I even considered to move /var to the root just
to test, but after reading more about the problem I decided not to pursue
this way.

It must be something else... Maybe I could try to remove nouveau just to
test. But since removing and adding nouveau is really hard, and the video
is working great, I want to check with you guys first for more fresh ideas.

Has anyone had trouble shutting down Buster? What other options do I have
to try to find the problem and a possible solution? Any other logs may be
of interest?

Thanks.

Bèco,
-- Linux user since it was called "just a hobby" (by L. Torvald)



-- 
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Re: Shutdown delay with LVM and disk encryption (SysV, buster)

[Bill Brelsford]

On Sat Aug 31 2019 at 03:40 PM +0200, Stefan Krusche wrote:
> Am Freitag, 30. August 2019 schrieb Bill Brelsford:
> > My 64-bit buster installation was created using its installer, with
> > / and /home partitions in an encrypted logical volume (sda3_crypt).
> > On shutdown, it pauses near the end with
> >
> >   Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt
> > busy...
> >
> > The busy messages continue for about 30 seconds, after which it
> > indicates "Failed" in red (I think, it happens fast) and shuts down
> > in a second or two.
> >
> > If I change to systemd, shutdown is fast (no delay).
> >
> > This appears to be similar to earlier bugs, e.g.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552,
> > except that they hung indefinitely.
> >
> > Anyone else seeing this?  Any suggestions or workarounds (other
> > than systemd)?  Thanks..
> 
> Hello Bill,
> 
> this behaviour had been discussed here, I think:
> 
> https://dev1galaxy.org/viewtopic.php?pid=11522#p11522
> 
> In that thread and others on that forum there are a couple of links to 
> other threads etc. about this issue.
> 
> The proposed solution is a patch which originated here:
> 
> https://bugs.devuan.org//cgi/bugreport.cgi?bug=237
> 
> …which I have applied on my system (devuan/ascii) and never seen this 
> problem again.

Thanks, Stefan -- that fixed it!

The cryptdisks-functions file no longer contains the "local dst .."
line, on buster anyway -- I inserted a "local vgs vg" line.  Total
shutdown time now about 7 seconds..

Regards..  Bill

Re: Shutdown delay with LVM and disk encryption (SysV, buster)

[Stefan Krusche]

Am Freitag, 30. August 2019 schrieb Bill Brelsford:
> My 64-bit buster installation was created using its installer, with
> / and /home partitions in an encrypted logical volume (sda3_crypt).
> On shutdown, it pauses near the end with
>
>   Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt
> busy...
>
> The busy messages continue for about 30 seconds, after which it
> indicates "Failed" in red (I think, it happens fast) and shuts down
> in a second or two.
>
> If I change to systemd, shutdown is fast (no delay).
>
> This appears to be similar to earlier bugs, e.g.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552,
> except that they hung indefinitely.
>
> Anyone else seeing this?  Any suggestions or workarounds (other
> than systemd)?  Thanks..

Hello Bill,

this behaviour had been discussed here, I think:

https://dev1galaxy.org/viewtopic.php?pid=11522#p11522

In that thread and others on that forum there are a couple of links to 
other threads etc. about this issue.

The proposed solution is a patch which originated here:

https://bugs.devuan.org//cgi/bugreport.cgi?bug=237

…which I have applied on my system (devuan/ascii) and never seen this 
problem again.


HTH,

Kind regards,
Stefan

Shutdown delay with LVM and disk encryption (SysV, buster)

[Bill Brelsford]

My 64-bit buster installation was created using its installer, with
/ and /home partitions in an encrypted logical volume (sda3_crypt).
On shutdown, it pauses near the end with

  Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt busy...

The busy messages continue for about 30 seconds, after which it
indicates "Failed" in red (I think, it happens fast) and shuts down
in a second or two.

If I change to systemd, shutdown is fast (no delay).

This appears to be similar to earlier bugs, e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552,
except that they hung indefinitely.

Anyone else seeing this?  Any suggestions or workarounds (other
than systemd)?  Thanks..

-- 
Bill Brelsford
wbr...@k2di.net

Re: Grrrrr, howinhell do I stop the 3 minutes of inactivity shutdown of a new stretch install?

[Jonathan Dowland]

On Wed, Apr 03, 2019 at 02:00:54PM -0400, Gene Heskett wrote:

I have gone thru the netinstall of 9.8.0 at least 5 times. 1st time
failed for unk reasons, but would not reboot.  2nd time I let the
partitioner have its way on a 2T drive wiith a separate /home, so it
gave / 30GB and and about 17 gb to swap, the rest to /home.  That
rebooted, but 30GB for / is about 100GB too small by the time I move my
data.  So the next 3 times I've manually given / 500 GB, some swap, and
the rest as /home. Won't boot, does not even look at the drive, just
sits there forever with a blinking cursor.
So just how the heck  am I supposed to install stretch on a 2T drive?


Remember to create a /boot partition.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.