Your session only lasted less than 10 seconds.

English Install/Boot/Login
#1

Hello,

I know this has been discussed more often, but after having Suse 11.0 installed for a while, I finally got Xen to work. Not someone to boot often unless really necessary, I rebooted after say two weeks, and now I am no longer able to log in to X with anything other than root.

Anytime I try, I get a message that the session lasted less than 10 seconds, and that I might have a disk space issue.
/home is a separate partition, / is 20 GiB big, and from what I can collect, /dev/sda1 seems to be full.

This is the first part of the .xsessionerrors file:

==========================================================
chown: changing ownership of /dev/xconsole': Operation not permitted chmod: changing permissions of /dev/xconsole’: Operation not permitted
/etc/X11/xim: Checking whether an input method should be started.
/etc/X11/xim: user environment variable LANG=en_US.UTF-8
sourcing /etc/sysconfig/language to get the value of INPUT_METHOD
INPUT_METHOD is set to none.
Trying to start this user selected input method first …
sourcing /etc/X11/xim.d/none
Dummy input method “none” (do not use any input method at all by default)
Start of none succeeded.
Warning: No symbols defined for <SYRQ> (keycode 92)

Then there are about 20-30 of these “Warning: No symbols” lines, followed by two or three of these:

==========================================================
GConf-ERROR **: Resource problem creating ‘/tmp/gconfd-thorwald’
aborting…
/usr/bin/gnome: line 22: 5605 Aborted gconftool-2 -u /desktop/gnome/background/picture_filename

Yes, I run Gnome, and yes, any other non-root user has the same issue (normally only have thorwald as a user, but I created a test-user).

I have seen several threads about this, but not found a solution other than re-installing yet…

Who can help?

#2

When you think you have a disk space issue (it SEEMS to be full), why don’t you just check if it IS full? Post the ouput of

df

And please post the answer between CODE tags (select that part of the post and click the # button in the toolbar) instead of putting ===== around the text.

#3

Thank you hcw for the reply.
I did indeed find that /dev/sda1 is used for 100%, but I’d like to find out with what and/or why.

Doing df I get the following:

TheMyth:~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             20641788  20628844         0 100% /
udev                   1866408       124   1866284   1% /dev
/dev/sda5            206428012    191980 195750008   1% /home
gvfs-fuse-daemon      20641788  20628844         0 100% /root/.gvfs
TheMyth:~ #

Knowing no other way, I did an ls -l on /dev/sda1:

TheMyth:~ # ls -l /dev/sda1
brw-r----- 1 root disk 8, 1 2009-01-26 17:15 /dev/sda1
TheMyth:~ #

What else can I find out what /dev/sda1 or indeed this gvfs-fuse-daemon keep hidden for me?

#4

OpenBokkie schrieb:
> I did indeed find that /dev/sda1 is used for 100%, but I’d like to find
> out with what and/or why.
>
> Doing -df- I get the following:
>
> Code:
> --------------------
> TheMyth:~ # df
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sda1 20641788 20628844 0 100% /
> udev 1866408 124 1866284 1% /dev
> /dev/sda5 206428012 191980 195750008 1% /home
> gvfs-fuse-daemon 20641788 20628844 0 100% /root/.gvfs
> TheMyth:~ #
> --------------------

/dev/sda1 hosts your root filesystem, which is full. That’s a critical
condition for a Unix/Linux system. Now 20 gigs would normally be quite
decent, given that you have a separate /home filesystem. But I notice
your /home is really not used much at all, which makes me suspect that
your files aren’t getting stored there, but somewhere in the root fs.
You aren’t logging in as root for regular use of your system, by any
chance???

> Knowing no other way, I did an -ls -l- on -/dev/sda1-:
>
> Code:
> --------------------
> TheMyth:~ # ls -l /dev/sda1
> brw-r----- 1 root disk 8, 1 2009-01-26 17:15 /dev/sda1
> TheMyth:~ #
> --------------------

Ah, no, that won’t help. /dev/sda1 is only the container, so to speak.
To look inside, you’d have to “ls -l” the mount point, ie.

ls -l /

But that will only reveal a list of directories (or, as the young
folk nowadays call them, folders) with no way of knowing how much
space each of them occupies. The tool for finding that out is “du”.
However, a simple

du /

will produce way too much output to be useful - it’ll actually
print a complete list of all directories in your system and the
amount of disk space they occupy.

> What else can I find out what -/dev/sda1- or indeed this
> -gvfs-fuse-daemon- keep hidden for me?

Don’t bother with the FUSE daemon, that is quite normal. Concentrate
on finding out where all the space in your root filesystem went.

As a first attempt, do:

du -s /*

This will list the space occupied, in k, by each of the top-level
directories directly below the root directory /. Note that this
will take several minutes to complete because it has to scan your
entire directory tree. Ignore /home which is on a separate
filesystem anyway, as well as /dev, /proc, and /sys which are
pseudo filesystems and don’t occupy real disk space, whatever du
says. Concentrate first on /root which is the home directory of
the root user and may accumulate user files if you make the
mistake of logging in as root. If there’s more than a few k
there, you should move all that to a regular user’s home
directory under /home and henceforth work as that user.
If that’s not where your space went, look at /tmp next which may
accumulate temporary files, ie. files that aren’t needed anymore
once the program creating them is done, but which are sometimes
left behind by programs not properly cleaning up behind them.
Finally, if /var occupies substantial space, have a closer
look at that with the command:

du -s /var/*

The directory names occupying the most space should give you an
idea which program is behind the hogging.

If you don’t know what to make of all that, just post the results
of the two “du” commands and I’ll try to interpret them for you.

HTH
T.

#5

also make sure to check /tmp as it can grow considerably over time if you haven’t configured in YaST to clean it at given times and on boot

#6

Delete Your zypper.log in /var/ .
Not long ago i had an issue where it took 24.5GB!!!
I don’t know the reason why and it doesn’t happen too often to file a bug.
At least that’s what i’d except taking my exp with that issue into account.

#7

Sorry, I went to bed and did not see your answer until now. But a lot of usefull help is already given above.

I recap:
your problem is that your / filesystem is full. Now it is at 100%, that means that most probalby it is root that did it, because non root users would be stopped filling up after say 90%.

Not long ago we had one person on the forum who managed to do this by logginng in as root in the GUI and using root for all his normal work (suggested above by Tilman Schmidt). Please tell us if this is true (i hope not, because this is a major sin in Unix/Linux paradise :wink: ).

Finding where it grew out of proportions: use the du command as suggested above.
First have a look at /tmp, first

du -sk /tmp

I have less then 100MB here, so when you have GB’s there, carry on with

du -sk /tmp/* | more

and look through it. When found where it goes, try to find out who does make all the stuff.

When /tmp is normal, do the same starting at / and search for abnormal sizes. Takes some time, but has to be done.

Come back here with the results when you think you need more help.

(And yes, ls /dev/sda1 is not very useful in this case).

#8

Thanks so much for all your suggestions.

As I am writing this on another PC, it will take some time for me to get all done and posted.

I do not normally log in as root to do my run-of-the-mill things.
I have a separate user “thorwald” for normal logins.
If that user would still be able to go into X, I would not even have posted here.
I use root now only to troubleshoot (yes, I could try logging in to a cli terminal too).

my preferred way of interacting with the system at root level is by using sudo (not even sudo su).

#9

That i all good practice. Forgive for thinking that you might …, but there was one a few weeks ago >:(

#10

du -s /* gave me this:

TheMyth:~ # du -s /*
8992	/bin
38656	/boot
124	/dev
97612	/etc
4	/help
108	/home
*203020	/lib*
13908	/lib64
16	/lost+found
4	/media
8	/mnt
*142320	/opt*
du: cannot access `/proc/1369/task/1369/fd/4': No such file or directory
du: cannot access `/proc/1369/task/1369/fdinfo/4': No such file or directory
du: cannot access `/proc/1369/fd/4': No such file or directory
du: cannot access `/proc/1369/fdinfo/4': No such file or directory
0	/proc
21132	/root
11032	/sbin
128	/srv
0	/sys
4	/test
164	/tmp
4012164	/usr
du: cannot access `/var/lib/ntp/proc/1369/task/1369/fd/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1369/task/1369/fdinfo/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1369/fd/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1369/fdinfo/4': No such file or directory
15901948	/var
TheMyth:~ #

/lib, /opt and /usr seem the big ones here… together with /var

du -sk /var/ | more* gives this info:

TheMyth:~ # du -sk /var/* | more
53684   /var/adm
108612  /var/cache
8       /var/games
du: cannot access `/var/lib/ntp/proc/1396/task/1396/fd/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1396/task/1396/fdinfo/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1396/fd/4': No such file or directory
du: cannot access `/var/lib/ntp/proc/1396/fdinfo/4': No such file or directory
15674800        /var/lib
24      /var/lock
63676   /var/log
0       /var/mail
4       /var/opt
932     /var/run
132     /var/spool
68      /var/tmp
8       /var/X11R6
12      /var/yp
TheMyth:~ #

**
/var/lib/** jumps out.
I’ve added --si to the command, and 15674800 comes down to 17GiB… that’ s the culprit right there…

Drilling further down, /var/lib/xen/ accounts for 16 of the 17GiB. I think I better restart, and give /var/lib/xen/ it’s own partition of 20GiB…

Or does anyone have another, less drastic suggestion?

#11

I do not use Xen. Is it possible that the disk space of virtual systems is in there?

May be to lure Xen gurus to your problem you should start a new thread with a title like “Xen uses 16GB in /var/lib/xen” or something like that. Also reading documentation of xen may help. There might be a config parameter to put this amount of space elsewhere (a seperate partition).

In any case we drilled down to a suspect :slight_smile:

#12

OpenBokkie schrieb:
> du -s /* gave me this:
…]
> 203020 /lib
> 142320 /opt
> 4012164 /usr
> 15901948 /var
> TheMyth:~ #
> --------------------
>
>
> -/lib-, -/opt- and -/usr- seem the big ones here…

Nah, that’s pretty normal. /usr in particular contains much of the actual
system files, so 4 GB isn’t terribly much. Mine’s bigger, anyway. :slight_smile:

> together with -/var-

Yeah, that’s definitely out of range.

> /var/lib/* jumps out.
> Drilling further down, /var/lib/xen/ accounts for 16 of the 17GiB.

Good work.

> I think I better restart, and give /var/lib/xen/ it’s own partition of
> 20GiB…
>
> Or does anyone have another, less drastic suggestion?

I’d guess that XEN has created the disk image files of your VMs there.
Why not just delete those from the command line? You’ll lose the VMs
either way, but this way you won’t have to reinstall the entire system.

Once you’ve got your system running again, look in the XEN documentation
for a way of specifying where to store the images. Recreate your VMs with
image files somewhere below your home directory, or even better, on a
separate partition mounted as /img or something like that.

HTH
T.

#13

Thank you guys for your help in troubleshooting the issue.
Indeed, as Tilman said, removing the VMs resolved the issue so far.

For now I’ll just leave Xen unused (it’s just a hobby anyway), and will read up on Xen to find out whether I can put the VMs on their own partition.