LxPupSc17.07.01 won't shutdown cleanly - Solved

[wimpy]

When I try to poweroff or reboot, the WM shuts down and I get a message that LxPupSc17.07.01 is shutting down. However, it doesn't poweroff or reboot but returns to the # prompt with a cursor. Putting in poweroff or reboot only starts up the same cycle - "LxPupSc17.07.01 is shutting down" and back to the # prompt and cursor. The only remedy is to do a hard reboot. Loading up LxPupSc17.07.01 again results in a normal boot as if nothing untoward has happened. I would be grateful for any help in troubleshooting this odd behaviour.

UPDATE I find that I can type at that # prompt

Code: Select all

 busybox reboot -d 3 -n 

(poweroff works as well) to get a "Terminated" reply after 3 secs and the reboot goes through.
There doesn't seem to be any message re the holdup using dmesg
UPDATE2 No help. Decided to abandon this thread. Rule 5.

[Sailor Enceladus]

I have a similar problem on some puppies sometimes. There seems to be at least 2 versions of the problem:

1. It hangs at Shutting Down indefinitely
2. It hangs at Shutting Down for like 15-30 seconds with no more messages, then says "unmonuting sda1, sda2, etc." and shuts down (seems to usually last longer depending on how long I've had my machine on for)

Not sure what it's doing this whole time. I think some messages as it's shutting down would be nice so you know what is the bottleneck or point it gets stuck at. busybox poweroff kills it instantly but of course things aren't unmounted correctly

[wimpy]

Thanks for the reply. Normally, after the "shutting down" message I get another message about the pupsave.sfs being already saved before the program terminates. In this case that doesn't happen, so I presume that it is hanging at the pupsave check. I'd hoped that someone would tell me which script was activated on clicking the reboot or poweoff button. It would then be possible to step through the script in debug mode. FWIW my Rule 5 states " If one distro has problems, try another".

[theru]

Both the poweroff and reboot commands execute /etc/rc.d/rc.shutdown followed by busybox poweroff or busybox reboot respectively.

According to your description it seems to hang when running the rc.shutdown script. This script can be made slightly more verbose by commenting out the following line:

Code: Select all

exec 1> /dev/null 2>&1

It's located near the beginning of the script

After doing that you should get a slightly more verbose shutdown procedure.

If that isn't enough you can try making it more verbose by changing the shebang line (first line of the script) of rc.shutdown from

Code: Select all

#!/bin/sh

to

Code: Select all

#!/bin/sh -x

You can get a sample of that level of verbosity by running bash -x in a terminal.

[wimpy]

Thanks for the reply. Stepping through rc.shutdown, I found that the hangup was on ifplugd.sh (the Ethernet daemon) in /etc//init.d. I effectively killed it - there is no Ethernet cable, so the daemon is not required. I am most grateful for your help and info. rc.shutdown seems to be working through OK so I'll change ABANDONED to Solved

[Sailor Enceladus]

Thanks theru and wimpy! That code was extremely useful. You are right wimpy, it happened after the "Session (not) saved" message for me too. From shutting down about 3 times so far, I found out that my biggest bottleneck is the swapoff -a line in rc.shutdown, I tried changing it to swapoff -av and it was indeed my 3GB swap file it was "unloading" for most of the shutdown time, which takes longer if I've had my laptop on for a few hours or been doing a lot. Maybe I'll try 1-2GB or putting it at the start of the drive or not using -a and see what helps. I figured that might have been the issue, but now I can see it clearly!

[wimpy]

Glad you found the answer. For me, the easiest way to step through was to use the line

Code: Select all

trap "set+x; sleep 5; set -x" debug

at the start of the script. I could then go off and make a cup of coffee while it stepped through (allowing 5 secs per line) until it reached the offending line.