Request for explanation of error message

Robert Heller heller at deepsoft.com
Sun Jul 28 23:46:19 UTC 2019


At Mon, 29 Jul 2019 03:19:48 +0800 "Ubuntu user technical support,  not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> On 29/07/2019, Bret Busby <bret.busby at gmail.com> wrote:
> > On 29/07/2019, Mike Marchywka <marchywka at hotmail.com> wrote:
> >> On Mon, Jul 29, 2019 at 01:01:03AM +0800, Bret Busby wrote:
> >>> And, as I got a no free space warning, although I can't find where
> >>> there is no free space, apart from the snap (?) area,
> >>>
> >>> "
> >>> bret at bret-MD34045-2521:~$ df -h
> >>> Filesystem      Size  Used Avail Use% Mounted on
> >>> udev             16G     0   16G   0% /dev
> >>> tmpfs           3.2G  1.6M  3.2G   1% /run
> >>> /dev/sda7        92G   58G   30G  67% /
> >>> tmpfs            16G  469M   16G   3% /dev/shm
> >>> tmpfs           5.0M  4.0K  5.0M   1% /run/lock
> >>> tmpfs            16G     0   16G   0% /sys/fs/cgroup
> >>> /dev/loop0      128K  128K     0 100% /snap/software-boutique/39
> >>> /dev/loop1      8.0M  8.0M     0 100% /snap/pulsemixer/23
> >>> /dev/loop7       88M   88M     0 100% /snap/core/5328
> >>> /dev/loop2      161M  161M     0 100% /snap/midori/451
> >>> /dev/loop3       72M   72M     0 100% /snap/software-boutique/31
> >>> /dev/loop4       87M   87M     0 100% /snap/ubuntu-mate-welcome/335
> >>> /dev/loop5       89M   89M     0 100% /snap/core/7270
> >>> /dev/loop8      8.0M  8.0M     0 100% /snap/pulsemixer/250
> >>> /dev/loop6       88M   88M     0 100% /snap/ubuntu-mate-welcome/199
> >>> /dev/sda1        96M   31M   66M  32% /boot/efi
> >>> /dev/sda8        92G   63G   25G  73% /home
> >>> tmpfs           3.2G   64K  3.2G   1% /run/user/1000
> >>> /dev/sda9        92G   61M   87G   1% /media/bret/Data1
> >>> /dev/sda10       92G   61M   87G   1% /media/bret/Data2
> >>> "
> >>>
> >>>
> >>> so I looked in the /var area, I noticed that the 48GB log file has
> >>> much smaller zipped predecessors;
> >>
> >> This is probably log rotate. From the sizes, absent some activity you
> >> know
> >> about,
> >> things probably went bad between 16th and 22nd and then escalated.
> >>
> >>>
> >>> "
> >>> bret at bret-MD34045-2521:~$ ls -l /var/log/lightdm/x*.*
> >>> -rw------- 1 root root 48233766147 Jul 28 02:49 /var/log/lightdm/x-0.log
> >>> -rw------- 1 root root     9770700 Jul 23 03:45
> >>> /var/log/lightdm/x-0.log.3.gz
> >>> -rw------- 1 root root    26392833 Jul 22 23:42
> >>> /var/log/lightdm/x-0.log.4.gz
> >>> -rw------- 1 root root         768 Jul 16 20:13
> >>> /var/log/lightdm/x-0.log.5.gz
> >>> -rw------- 1 root root         784 Jul 15 16:42
> >>> /var/log/lightdm/x-0.log.6.gz
> >>> -rw------- 1 root root         144 Jul 14 21:33
> >>> /var/log/lightdm/x-0.log.7.gz
> >>> -rw------- 1 root root         100 Jul 13 01:14
> >>> /var/log/lightdm/x-0.log.8.gz
> >>> "
> >>>
> >>> Weirdness abounds.
> >>>
> >>> I note that, in the /var/log/lightdm directory, the other log files
> >>> have log1.gz and log2.gz , but, that one does not;
> >>>
> >>> "
> >>> bret at bret-MD34045-2521:~$ ls -l /var/log/lightdm/
> >>> total 47138780
> >>> -rw------- 1 root root           0 Jul 28 02:53 lightdm.log
> >>> -rw------- 1 root root        2822 Jul 28 02:50 lightdm.log.1.gz
> >>> -rw------- 1 root root        2130 Jul 23 03:46 lightdm.log.2.gz
> >>> -rw------- 1 root root         121 Jul 22 23:42 lightdm.log.3.gz
> >>> -rw------- 1 root root        2252 Jul 16 20:13 lightdm.log.4.gz
> >>> -rw------- 1 root root        1747 Jul 15 16:43 lightdm.log.5.gz
> >>> -rw------- 1 root root        1691 Jul  7 01:09 lightdm.log.6.gz
> >>> -rw------- 1 root root        1673 Jul  6 23:23 lightdm.log.7.gz
> >>> -rw------- 1 root root           0 Jul 28 02:53 seat0-greeter.log
> >>> -rw------- 1 root root        2294 Jul 28 02:50 seat0-greeter.log.1.gz
> >>> -rw------- 1 root root        1912 Jul 23 03:46 seat0-greeter.log.2.gz
> >>> -rw------- 1 root root        1934 Jul 16 20:13 seat0-greeter.log.3.gz
> >>> -rw------- 1 root root        1459 Jul 15 16:43 seat0-greeter.log.4.gz
> >>> -rw------- 1 root root        1501 Jul  7 01:09 seat0-greeter.log.5.gz
> >>> -rw------- 1 root root        1432 Jul  6 23:23 seat0-greeter.log.6.gz
> >>> -rw------- 1 root root        1429 Jul  6 23:33 seat0-greeter.log.7.gz
> >>> -rw------- 1 root root 48233766147 Jul 28 02:49 x-0.log
> >>> -rw------- 1 root root     9770700 Jul 23 03:45 x-0.log.3.gz
> >>> -rw------- 1 root root    26392833 Jul 22 23:42 x-0.log.4.gz
> >>> -rw------- 1 root root         768 Jul 16 20:13 x-0.log.5.gz
> >>> -rw------- 1 root root         784 Jul 15 16:42 x-0.log.6.gz
> >>> -rw------- 1 root root         144 Jul 14 21:33 x-0.log.7.gz
> >>> -rw------- 1 root root         100 Jul 13 01:14 x-0.log.8.gz
> >>> "
> >>>
> >>> So, I am assuming that that file corrupted, on or about 23 July, or,
> >>> whatever automatically compacts and archives it, and, starts a new log
> >>> file, failed, at about that time.
> >>
> >> Again, that is probably logrotate but the easiest thing to do is look at
> >> the
> >> last few lines
> >> in any of the larger files and find similar lines farther up to establish
> >> a
> >> period of
> >> error messages ( while they could all be unrelated as if being attacked
> >> likely it is in an
> >> infinite loop trying to get something restarted ). Once you have a full
> >> period it
> >> may be obvious what the problem is. Alternative, if you unzip the
> >> x-0.log.4.gz file to the
> >> console and just "more" it probably a few lines in you will see whatver
> >> started it
> >> as the earlier gzip files are quite small.
> >>
> >> If you boot in single user mode and have the console messages pop up, you
> >> may
> >> be able to execute some of the failed steps by hand and see if it
> >> triggers
> >> any error messages.
> >>
> >
> > Whatever is happeing, I now have
> >
> > "
> > bret at bret-MD34045-2521:~$ ls -l /var/log/lightdm/x*.*
> > -rw------- 1 root root 64086904832 Jul 29 02:49 /var/log/lightdm/x-0.log
> > "
> >
> > and no space left on the / partition.
> >
> > So, whatever is happening, the file, as it stands, has to be deleted,
> > as it has rendered the system unusable.
> >
> 
> 
> And, after having run
> sudo rm /var/log/lightdm/x-0.log
> whilst the file no longer shows as being present, the space has not
> been freed; still no free space in the / partition.

It won't be freed until the file is *closed*, and that won't happen 
until lightdm dies or is killed.  You can *try* sudo kill -HUP <lightdm's 
PID>, or reboot the system.

> 
> In going through the folders displayed by caja, in the / partition, I
> note that proc shows as having about 875,000 items, "totalling 140.7TB
> (0 bytes on disk)" (magic?).
> 
> The size of the HDD is 1TB.
> 
> /root and /lost+found are both unreadable when I try to find their
> Properties, and, I can't find the deleted file anywhere else, to free
> up its space, to provide free space in the / partition.
> 

Reboot the system.

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services
                                          




More information about the ubuntu-users mailing list