[Solved ?] Re: fsck forced when using /sbin/shutdown
On Mon, 2012-04-23 at 20:43 +, Camaleón wrote: [...] Mmm... what worries me is why an fsck is even needed just because a non- vital application is not being closed gracefully on shutdown, that's not something I would consider worth for a fsck :-? Steven, have you considered a hardware related problem? Just in case, running smartctl over the disk that holds the partition won't hurt. I checked the drive with gsmartcontrol, no errors found. The problem hasn't occurred with normal use for the past 2 days, so I assume an update fixed it. Kind regards, Steven signature.asc Description: This is a digitally signed message part
Re: fsck forced when using /sbin/shutdown
On Fri, 2012-04-20 at 15:09 +, Camaleón wrote: [...] /dev/sdc1 is the partition with data inconsistency, what we have to find out is why it's left in such state. Another possibility, should you have the chance, could be backup the full partition, reformat it and start over. Being just your /home this won't present any difficulty. Apart from the fact that I need someway to backup the data :) While not crucial data, I'd rather keep it. It's just a bit too big to add to my current backup system. I wonder what difference can be in shutting down from GNOME and doing it from the command line, mmm... :-? Is is perhaps possible that Gnome is writing out some config files in my home directory during shutdown and the system cuts power prematurely? I also noticed a message saying the device from / is busy during the shutdown sequence, but never /home, while the root filesystem doesn't need the check. (...) Yes, that was indeed the aim of my dumb suggestion :-) Well, any suggestion is welcome. I did some tests and it doesn't look like it's Gnome itself, at least not right after booting. First test: 1) boot 2) log in using a tty instead of gdm (Ctrl + Alt + F1) 3) issue the sudo /sbin/shutdown -h +1 command result: no fsck needed Second test: 1) boot 2) log in using gdm3 and starting a regular Gnome session 3) switch to tty1, login there 4) issue the sudo /sbin/shutdown -h +1 command result: no fsck needed Third test: I changed the +1 to +2, so as to give the previous command in the script enough time (which is a killall java). After normal operation, the command is issued, but this time a fsck was needed again. I'm thinking about it, there are only 2 applications running right before that command gets executed. - Vuze - pgl-gui (peerguardian for Linux) The complete script actually looks like this: vlc -f play killall java sudo /sbin/shutdown -h +2 vlc is started full screen with playlist file play, the last item in the playlist tells vlc to exit. Then killall java is executed to tell vuze to terminate (failing to do so results in vuze complaining about suddenly being stopped, due to the shutdown procedure). That is also the reason for the 1 minute delay, so as to give Vuze enough time to properly terminate. I had no problems with this before the reinstall. I'll remember to stop pgl-gui today, if that doesn't fix it, I'm out of ideas. Kind regards, Steven signature.asc Description: This is a digitally signed message part
Re: fsck forced when using /sbin/shutdown
On Mon, Apr 23, 2012 at 11:54, Steven Post redalert.comman...@gmail.com wrote: I'm thinking about it, there are only 2 applications running right before that command gets executed. - Vuze - pgl-gui (peerguardian for Linux) The complete script actually looks like this: vlc -f play killall java sudo /sbin/shutdown -h +2 vlc is started full screen with playlist file play, the last item in the playlist tells vlc to exit. Then killall java is executed to tell vuze to terminate (failing to do so results in vuze complaining about suddenly being stopped, due to the shutdown procedure). That is also the reason for the 1 minute delay, so as to give Vuze enough time to properly terminate. I had no problems with this before the reinstall. I'll remember to stop pgl-gui today, if that doesn't fix it, I'm out of ideas. Is it possible to shutdown vuze gracefully instead of killing java out from under it? Or there are a lot of torrent clients that are likely to be better behaved than vuze... Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFoWM=93TFG67d9B=AOnoONjECEQux+dziUtCsy=sx+q781...@mail.gmail.com
Re: fsck forced when using /sbin/shutdown
On Mon, 2012-04-23 at 12:07 -0700, Kelly Clowers wrote: [...] Is it possible to shutdown vuze gracefully instead of killing java out from under it? I couldn't find anything back when I wrote the script besides killing java. But I just did another search and came up with vuze --closedown which seems to work fine. Or there are a lot of torrent clients that are likely to be better behaved than vuze... True, but I find that they lack configuration options with regard to queuing. I searched for other clients before, as Vuze was having regular crashes (whether this was down to Vuze or the JRE used, I don't know, but it doesn't crash anymore, so it isn't as much of an issue anymore). That aside, I don't believe it is Vuze's fault that the filesystem is corrupted, for that matter, I think it is up to the OS to prevent that by killing the applications, then writing out the remaining buffers and cleanly unmount the filesystem. Which is clearly not happening here, however I'm fairly sure that about any Linux system, especially Debian, does this kind of thing right, leaving aside power failures and hardware problems. Still puzzled about this. Kind regards, Steven signature.asc Description: This is a digitally signed message part
Re: fsck forced when using /sbin/shutdown
On Mon, 23 Apr 2012 20:54:31 +0200, Steven Post wrote: On Fri, 2012-04-20 at 15:09 +, Camaleón wrote: [...] /dev/sdc1 is the partition with data inconsistency, what we have to find out is why it's left in such state. Another possibility, should you have the chance, could be backup the full partition, reformat it and start over. Being just your /home this won't present any difficulty. Apart from the fact that I need someway to backup the data :) While not crucial data, I'd rather keep it. It's just a bit too big to add to my current backup system. Okay then :-) Is is perhaps possible that Gnome is writing out some config files in my home directory during shutdown and the system cuts power prematurely? I also noticed a message saying the device from / is busy during the shutdown sequence, but never /home, while the root filesystem doesn't need the check. (...) Yes, that was indeed the aim of my dumb suggestion :-) Well, any suggestion is welcome. I did some tests and it doesn't look like it's Gnome itself, at least not right after booting. First test: 1) boot 2) log in using a tty instead of gdm (Ctrl + Alt + F1) 3) issue the sudo /sbin/shutdown -h +1 command result: no fsck needed Second test: 1) boot 2) log in using gdm3 and starting a regular Gnome session 3) switch to tty1, login there 4) issue the sudo /sbin/shutdown -h +1 command result: no fsck needed Third test: I changed the +1 to +2, so as to give the previous command in the script enough time (which is a killall java). After normal operation, the command is issued, but this time a fsck was needed again. Mmm... what worries me is why an fsck is even needed just because a non- vital application is not being closed gracefully on shutdown, that's not something I would consider worth for a fsck :-? Steven, have you considered a hardware related problem? Just in case, running smartctl over the disk that holds the partition won't hurt. I'm thinking about it, there are only 2 applications running right before that command gets executed. - Vuze - pgl-gui (peerguardian for Linux) The complete script actually looks like this: vlc -f play killall java sudo /sbin/shutdown -h +2 vlc is started full screen with playlist file play, the last item in the playlist tells vlc to exit. Then killall java is executed to tell vuze to terminate (failing to do so results in vuze complaining about suddenly being stopped, due to the shutdown procedure). That is also the reason for the 1 minute delay, so as to give Vuze enough time to properly terminate. I had no problems with this before the reinstall. When you shutdown the system all of the opened applications and those in memory should be automatically closed but yet again, IMO a fsck is too much for an application that was not closed properly. I'll remember to stop pgl-gui today, if that doesn't fix it, I'm out of ideas. Well, to discard any of these applications as the source of the problem, you can manually run the commands of the script, one by one and before you issue the shutdown run ps to check whether there's any instance of that applications running in the background and if so, kill them and then proceed with the shutdown. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jn4et7$68l$9...@dough.gmane.org
Re: fsck forced when using /sbin/shutdown
On Thu, 19 Apr 2012 20:54:46 +0200, Steven Post wrote: On Thu, 2012-04-19 at 17:31 +, Camaleón wrote: And is it true that there were errors? What does the fsck log say? I found no further clue in /var/log/fsck/checkfs, here is the complete output: (...) /dev/sdc1 contains a file system with errors, check forced. /dev/sdc1: 398799/38772736 files (3.9% non-contiguous), 112892386/155062264 blocks Mmm, the file system on that partition had errors, the fsck was right. I can see the fsck making progress and after it reaches 100% the system just continues to boot. sde1 in this case is /boot on the SSD, sdc1 is /home on the HDD. The lvm volume I hadn't mentioned are different hard drives, those don't cause any problems and were present in the same configuration on the previous install. /dev/sdc1 is the partition with data inconsistency, what we have to find out is why it's left in such state. Another possibility, should you have the chance, could be backup the full partition, reformat it and start over. Being just your /home this won't present any difficulty. I wonder what difference can be in shutting down from GNOME and doing it from the command line, mmm... :-? Is is perhaps possible that Gnome is writing out some config files in my home directory during shutdown and the system cuts power prematurely? I also noticed a message saying the device from / is busy during the shutdown sequence, but never /home, while the root filesystem doesn't need the check. (...) Yes, that was indeed the aim of my dumb suggestion :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jmru7s$o0u$1...@dough.gmane.org
Re: fsck forced when using /sbin/shutdown
On Wed, 18 Apr 2012 21:19:09 +0200, Steven Post wrote: I have this really annoying problem when I shutdown the machine using sudo /sbin/shutdown -h +1 The machine seems to properly shutdown, but I always (at least I think) get the message that a filesystem contains errors and needs to be checked. When I use the shutdown option in Gnome, the system boots fine without the fsck. And is it true that there were errors? What does the fsck log say? I wonder what difference can be in shutting down from GNOME and doing it from the command line, mmm... :-? This is really annoying, especially as both / and /boot are on an SSD, the system that is checked is always another rotational hard disk mounted on /home. The problem started when I reinstalled Debian Wheezy on the new SSD, using the AMD64 architecture. At the same time I got rid of an old, unused, partition on the HDD and extended the existing ext4 partition to include the newly claimed space. All this using the Debian installer. Before the reinstall the system was running Wheezy on the i386 architecture and the now extended partition was already used as /home, it was not changed other then extending it. Any ideas? One dumb idea, yup. Before you shutdown the system from command line, logout from your current GNOME session, go to a tty and then run the shutdown sequence from there. Is the fsck still coming up when you boot? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jmpi51$kai$1...@dough.gmane.org
Re: fsck forced when using /sbin/shutdown
On Thu, 2012-04-19 at 17:31 +, Camaleón wrote: On Wed, 18 Apr 2012 21:19:09 +0200, Steven Post wrote: I have this really annoying problem when I shutdown the machine using sudo /sbin/shutdown -h +1 The machine seems to properly shutdown, but I always (at least I think) get the message that a filesystem contains errors and needs to be checked. When I use the shutdown option in Gnome, the system boots fine without the fsck. And is it true that there were errors? What does the fsck log say? I found no further clue in /var/log/fsck/checkfs, here is the complete output: ### Log of fsck -C -R -A -a Thu Apr 19 20:21:12 2012 fsck from util-linux 2.20.1 /dev/sde1: clean, 241/61056 files, 13476/243968 blocks /dev/sdc1 contains a file system with errors, check forced. /dev/sdc1: 398799/38772736 files (3.9% non-contiguous), 112892386/155062264 blocks /dev/mapper/mydatavolumegroup-mydatalv: clean, 285499/183148544 files, 723935104/732567552 blocks (check in 2 mounts) fsck died with exit status 1 # I can see the fsck making progress and after it reaches 100% the system just continues to boot. sde1 in this case is /boot on the SSD, sdc1 is /home on the HDD. The lvm volume I hadn't mentioned are different hard drives, those don't cause any problems and were present in the same configuration on the previous install. I wonder what difference can be in shutting down from GNOME and doing it from the command line, mmm... :-? Is is perhaps possible that Gnome is writing out some config files in my home directory during shutdown and the system cuts power prematurely? I also noticed a message saying the device from / is busy during the shutdown sequence, but never /home, while the root filesystem doesn't need the check. [...] Any ideas? One dumb idea, yup. Before you shutdown the system from command line, logout from your current GNOME session, go to a tty and then run the shutdown sequence from there. Is the fsck still coming up when you boot? I'll try that this evening, thanks for the suggestion. Kind regards, Steven signature.asc Description: This is a digitally signed message part
