StartX doesn't work. (Not enough space?)

4

My Debian was working perfectly till yesterday. I had installed reaver, aircrack and kismet and played with them for a while (could they be the culprit?). But now the x server doesn't connect. I don't have a desktop manager installed so I always manually startx-ed(wm=awesome) without any problems. Now I can't. I will write down the symptoms here. I hope you guys will diagnose the problem and suggest solutions.

  1. What startx says: The XKEYBOARD keymap compiler (xkbcomp) reports:

    Error: cannot close "/tmp/server-0.xkm" properly (not enough space?) ... output file "tmp/server-0.xkm" removed.
Errors from xkbcomp are not fatal.
AIGLX:suspending AIGLX clients for VT switch (EE) server terminated with error (1) ...

    The xorg.0.log file says basically the same thing. (Keyboard initialization failed, could be missing or incorrect setup of xkeyboard-config)

    What is peculiar is that it reports there might not be enough space. The last time I checked there was more than enough space(20 gigs) left.

  2. When I purged reaver, kismet and aircrack: Everything goes fine but it says it cant update mandb because it doesnt have space.

  3. ls on / : When I cd /;ls, the /tmp directory is the only directory which is highlighted with green color(bg = green, fg = black). I think it is suspicious.

  4. When I delete .Xsessions file and then startx: The error messages regarding keyboard are gone but AIGLX clients are still being suspended (server terminates with error)

  5. What I df -i says: Every thing is fine, only 10% inodes used.

  6. What df -h says: What???? It says root partition is completely filled up. (24 out of 24 gigs) I did apt-get clean and it still says it is completely filled.

Okay guys we all know what the problem is: root is completely filled. Of course I didn't do it. It would take way too long to download 20 gigs of data for me not to notice (I have a 20 kbps download speed). Also, it would take long enough to write so much data as log or something. (Root is write protected anyways.)

Someone in the forums claimed to have fixed the problem by pacman -Scc. I did try apt-get clean and it didn’t work.

Thus now I am turning towards you guys for help. Please suggest what I should try next.

Nirav

Posted 2016-09-22T07:29:10.793

Reputation: 188

I meant to post it in unix.stackoverflow but I mistakenly did it here. I will move it after 40 mins. – Nirav – 2016-09-22T07:38:03.930

Have you tried identifying which directory is responsible for filling your partition? Try, as sudo, du -h --max-depth=1 -x. – MariusMatutiae – 2016-09-22T08:57:26.677

Your question is on-topic for both [su] and [unix.se] so it's fine to post on either. I've just suggested an edit which adds Markdown formatting to make it easier to read the question. – Anthony Geoghegan – 2016-09-22T10:36:34.713

@MariusMatutiae du did the trick and I successfully eliminated the huge logs. Thanks for the suggestion. – Nirav – 2016-09-22T14:20:58.090

@AnthonyGeoghegan Thanks for formatting it. I was using my mobile browser back then so I couldn't do it. – Nirav – 2016-09-22T14:22:41.967

No problem. You provided lots of useful information and I thought I'd try to make easier for people to parse it all. Now that I think about it, your question should get an upvote for showing lots of research effort and clearly stating the problem with lots of relevant details. Welcome to [se]. – Anthony Geoghegan – 2016-09-22T16:14:23.390

Answers

2

When df reports that a partition is full, the du command is the next step in diagnosing the problem. I would cd to the filesystem root and run

sudo du -smx * .[^.]* | sort -n
  • The -s (--summarize) option prints the total size for each file/directory.
  • The -m option prints the disk space used by each file/directory in Megabytes.
  • The -x (--one-file-system) option forces du to remain on the initial filesystem. This leaves out irrelevant (to this end!) info like all files in /run, /sys, /dev and/or /proc (thanks, MariusMatutiae).
  • The [^.].* includes hidden files while excluding the parent directory, ..).
  • Finally, sorting the list numerically conveniently displays the directories taking up the most amount of space at the end of the list.

I then change into the directory taking up the most space and repeat the process for its subdirectories. Eventually you should find a directory that’s using more space than it should be.

By the way, /tmp/ is meant to be world writeable (resulting in the green background). Its contents should automatically be deleted by the OS regularly – but you might need to manually delete old files that weren’t automatically cleaned up.

Personally, I always mount /home to a separate filesystem to and whenever this happened to me, I found the culprit to be the log files in /var/log.

Anthony Geoghegan

Posted 2016-09-22T07:29:10.793

Reputation: 3 095

You may want to add the option -x, which forces du to remain on the initial filesystem. This leaves out irrelevant (to this end!) info like all files in /run, /sys, /boot, /dev, /lost+found.... – MariusMatutiae – 2016-09-22T09:18:12.117

Thanks @MariusMatutiae I've edited my answer to include that option. – Anthony Geoghegan – 2016-09-22T09:43:41.447

1Ahh thanks. The culprits were those log files in /var just as you predicted. I wonder what caused that inflation overnight. – Nirav – 2016-09-22T14:14:46.487

1It's worth checking the logs to see what's happening that so much is being logged and try to prevent it from recurring. I know some administrators mount /var/log on a separate partition to avoid this very issue. It's probably best practice and I really should do it, myself. – Anthony Geoghegan – 2016-09-22T16:18:37.190

Some, but rarely, you may even run out of inodes with similar symptoms - 'df -i' can help check if you suspect that might be the case. – Fred Clausen – 2016-09-24T02:37:28.720

Asked: 2016-09-22T07:29:10.793

Viewed: 781 times

Active: 2016-09-22T11:40:59.900