SOLVED - Shutdown won't

[Maurice]

Common problem - I've done a search but to no avail. PcLinuxos 2010 fully updated. It sticks on the Shutting down the system screen about an inch from the end but  if it does get to the end it fails to close anyway and hangs tight.

The keyboard is inoperative and I have to use the reset button to try again - up to three times. Sometimes I have to open Windows to close shop.

I have tried /usr/bin/halt and various combinations of Shutdown in a terminal but each one merely returns me to the above gui Shutting down....

I've tried ctrl/esc to check services running but don't know how to interpret them.

Any suggestions would be much appreciated.

[Vortеx]

While booting and halting there is a text output "behind" the plymouth theme.
Press Esc when you see it and should be able to see at what procedure system freezes.

[Maurice]

While booting and halting there is a text output "behind" the plymouth theme.
Press Esc when you see it and should be able to see at what procedure system freezes.

Thanks Vorteks but there's no text output and pressing Esc does nothing.

[Maurice]

While booting and halting there is a text output "behind" the plymouth theme.
Press Esc when you see it and should be able to see at what procedure system freezes.

Thanks Vorteks but there's no text output and pressing Esc does nothing.

You were right after all Vorteks. Although there was no text output I pressed Esc whilst the  Shutting down the system was moving and the text came up. And -- it shut down.

I'll check it the next time I close up and try and work it out.

Many thanks.

[Archie]

Unusual fix but if it works, it works!

Good one, Vorteks!

bin bash!

[Vortеx]

Unusual fix but if it works, it works!

bin bash!

set reboot=Esc!

I am curious if the situation for Maurice repeats.

[Archie]

If it doesn't, tell him to mark the thread as solved.

[Maurice]

Unusual fix but if it works, it works!

bin bash!

set reboot=Esc!

I am curious if the situation for Maurice repeats.

Unfortunately it didn't. However there were a number of loops detected.

Network -  Ignoring - requires pktcdvd
Avahi-daemon
Network up bpa login

or words to those effects. Don't know how to fix them though.

[Vortеx]

However there were a number of loops detected.

Network -  Ignoring - requires pktcdvd
Avahi-daemon
Network up bpa login

or words to those effects. Don't know how to fix them though.

I can't help here but you didn't specify the loops are on boot or on halt?

[Maurice]

I can't help here but you didn't specify the loops are on boot or on halt?

On Halt (or Shutdown). Booting is no problem.

[Archie]

I am not sure what you have posted, Maurice so am I right in assuming that your network connection is not properly killall which is why your shutdown process is taking too long, waiting for these processes (network, avahi-daemon) to be closed?

[Maurice]

I am not sure what you have posted, Maurice so am I right in assuming that your network connection is not properly killall which is why your shutdown process is taking too long, waiting for these processes (network, avahi-daemon) to be closed?

Yes, Archie, it seems so from the loops I'm getting. But the shutdown is not just taking too long - it doesn't shutdown at all.

[Archie]

I am not sure what you have posted, Maurice so am I right in assuming that your network connection is not properly killall which is why your shutdown process is taking too long, waiting for these processes (network, avahi-daemon) to be closed?

Yes, Archie, it seems so from the loops I'm getting. But the shutdown is not just taking too long - it doesn't shutdown at all.

Let me explain a little bit... your system is not shutting down properly therefore the filesystem is not getting umounted correctly either, which might eventually lead to a compromised  system integrity ... in short, this is definitely not good.

For the filesystem to be correctly umounted, there is a killall for all the processes, and in your case killall is ineffective to one or two of your running processes. We know its something in Network.

Do you have samba shares mounted? Are you using wireless or wired?

There's a couple of things I want you to try ... on a terminal (don't be afraid) ...

[user@localhost ~]$ ifconfig  [Enter]

and tell us the output ... only need to know if it's eth0 or eth1 or wlan0 or maybe even something else unusual.

Before shutting down, try the command

[root@localhost ~]# ifdown <network_device>  [Enter]   //where <network_device> is either eth0, eth1, wlan0, etc.

The tell us what happened on your next reboot.

[Maurice]

I am not sure what you have posted, Maurice so am I right in assuming that your network connection is not properly killall which is why your shutdown process is taking too long, waiting for these processes (network, avahi-daemon) to be closed?

Yes, Archie, it seems so from the loops I'm getting. But the shutdown is not just taking too long - it doesn't shutdown at all.

Let me explain a little bit... your system is not shutting down properly therefore the filesystem is not getting umounted correctly either, which might eventually lead to a compromised  system integrity ... in short, this is definitely not good.

For the filesystem to be correctly umounted, there is a killall for all the processes, and in your case killall is ineffective to one or two of your running processes. We know its something in Network.

Do you have samba shares mounted? Are you using wireless or wired?

There's a couple of things I want you to try ... on a terminal (don't be afraid) ...

[user@localhost ~]$ ifconfig  [Enter]

and tell us the output ... only need to know if it's eth0 or eth1 or wlan0 or maybe even something else unusual.

Before shutting down, try the command

[root@localhost ~]# ifdown <network_device>  [Enter]   //where <network_device> is either eth0, eth1, wlan0, etc.

The tell us what happened on your next reboot.

Samba shares --  No
Wireless  -- wlan0

Ain't afraid of the terminal Archie.

Here 'tis

[mihi@localhost ~]$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1C:C0:38:A8:77  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:20 Memory:e3200000-e3220000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:78 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3900 (3.8 KiB)  TX bytes:3900 (3.8 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:25:9C:A8:72:DE
          inet addr:10.0.0.7  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::225:9cff:fea8:72de/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22275 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22670457 (21.6 MiB)  TX bytes:5378547 (5.1 MiB)


[root@localhost mihi]# ifdown wlan0
[root@localhost mihi]#

My connection dropped when I typed this command but it may have been something else

When I turned the machine off it shut down first time. My next reboot was as normal.

[Archie]

[root@localhost mihi]# ifdown wlan0
[root@localhost mihi]#

My connection dropped when I typed this command but it may have been something else

When I turned the machine off it shut down first time. My next reboot was as normal.

The highlighted sentence means you were able to shutdown properly when you dropped the connection? What do you mean first time?

In doing the same procedure again, did the machine shutdown properly or not?