Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #212223 > unrolled thread

where is my disk space

Started byLong Wind <longwind2@yahoo.com>
First post2019-08-04 10:40 +0200
Last post2019-08-04 12:00 +0200
Articles 20 on this page of 22 — 9 participants

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-04 10:40 +0200
    Re: where is my disk space <tomas@tuxteam.de> - 2019-08-04 11:30 +0200
      Re: where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-04 11:40 +0200
        Re: where is my disk space Étienne Mollier <etienne.mollier@mailoo.org> - 2019-08-04 11:50 +0200
          Re: where is my disk space Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-04 12:00 +0200
            Re: where is my disk space Étienne Mollier <etienne.mollier@mailoo.org> - 2019-08-04 12:30 +0200
        Re: where is my disk space "Thomas Schmitt" <scdbackup@gmx.net> - 2019-08-04 12:00 +0200
        Re: where is my disk space <tomas@tuxteam.de> - 2019-08-04 12:30 +0200
          Re: where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-04 12:50 +0200
            Re: where is my disk space Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-08-04 13:10 +0200
              Re: where is my disk space David Wright <deblis@lionunicorn.co.uk> - 2019-08-04 17:40 +0200
                Re: where is my disk space Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-08-04 23:40 +0200
                Re: where is my disk space David Wright <deblis@lionunicorn.co.uk> - 2019-08-05 06:10 +0200
                  Re: where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-05 06:20 +0200
                    Re: where is my disk space davidson <davidson@freevolt.org> - 2019-08-05 18:10 +0200
                      Re: where is my disk space Curt <curty@free.fr> - 2019-08-05 18:40 +0200
                        Re: where is my disk space David Wright <deblis@lionunicorn.co.uk> - 2019-08-06 02:10 +0200
                          Re: where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-12 10:00 +0200
                            Re: where is my disk space David Wright <deblis@lionunicorn.co.uk> - 2019-08-12 16:50 +0200
                              Re: where is my disk space Long Wind <longwind2@yahoo.com> - 2019-08-13 01:00 +0200
      Re: where is my disk space Étienne Mollier <etienne.mollier@mailoo.org> - 2019-08-04 11:40 +0200
    Re: where is my disk space Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-04 12:00 +0200

Page 1 of 2  [1] 2  Next page →

#212223 — where is my disk space

FromLong Wind <longwind2@yahoo.com>
Date2019-08-04 10:40 +0200
Subjectwhere is my disk space
Message-ID<yrkdA-5je-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

i have stretch at sda2, which has 9.8Gfree space is far more than 1 Gbut some program i'm unware of take all space
how to find out and solve? Thanks!

[toc] | [next] | [standalone]

#212225

From<tomas@tuxteam.de>
Date2019-08-04 11:30 +0200
Message-ID<yrkZX-5PP-3@gated-at.bofh.it>
In reply to#212223

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 04, 2019 at 08:32:00AM +0000, Long Wind wrote:
> i have stretch at sda2, which has 9.8Gfree space is far more than 1 Gbut some program i'm unware of take all space
> how to find out and solve? Thanks!

Your request is too general for a meaningful answer.

First off, space on a file system is taken up by "files". If you want
to find out where the space is missing, "du" is a good command.

Files live on file systems, so "sda2" (the device) is pretty meaningless
in this context [1]. Let's assume /dev/sda2 is mounted on / -- then

  sudo du -sh /*

will give you, directory for directory, where the space goes (the option
"-s" says "summary", the option "-h" is for "human readable" (i.e. it
would say "1.2G" instead of "1201345", for example).

Then you can work your way down. May be you find a file you "know" and
decide you can remove it. Maybe you aren't sure -- then the next step
would be to find out which program is generating those files.

There are many details I left off, but you'd have to be more specific
if you want more specific help.

Cheers

[1] Blame stupid desktop environments for leading users to mix up
   all that stuff.

-- tomás

[toc] | [prev] | [next] | [standalone]

#212226

FromLong Wind <longwind2@yahoo.com>
Date2019-08-04 11:40 +0200
Message-ID<yrl9E-5Tj-13@gated-at.bofh.it>
In reply to#212225

[Multipart message — attachments visible in raw view] — view raw

 thank!  i enter "du -sh /home", it's 5.8G. it's unbelievable

i enter "df -h"Filesystem      Size  Used Avail Use% Mounted on
udev            1.5G     0  1.5G   0% /dev
tmpfs           298M  4.5M  293M   2% /run
/dev/sda2       9.8G  9.3G     0 100% /......

0.5 G seems missing

    On Sunday, August 4, 2019, 5:27:01 PM GMT+8, <tomas@tuxteam.de> wrote:  
 
 On Sun, Aug 04, 2019 at 08:32:00AM +0000, Long Wind wrote:
> i have stretch at sda2, which has 9.8Gfree space is far more than 1 Gbut some program i'm unware of take all space
> how to find out and solve? Thanks!

Your request is too general for a meaningful answer.

First off, space on a file system is taken up by "files". If you want
to find out where the space is missing, "du" is a good command.

Files live on file systems, so "sda2" (the device) is pretty meaningless
in this context [1]. Let's assume /dev/sda2 is mounted on / -- then

  sudo du -sh /*

will give you, directory for directory, where the space goes (the option
"-s" says "summary", the option "-h" is for "human readable" (i.e. it
would say "1.2G" instead of "1201345", for example).

Then you can work your way down. May be you find a file you "know" and
decide you can remove it. Maybe you aren't sure -- then the next step
would be to find out which program is generating those files.

There are many details I left off, but you'd have to be more specific
if you want more specific help.

Cheers

[1] Blame stupid desktop environments for leading users to mix up
  all that stuff.

-- tomás

[toc] | [prev] | [next] | [standalone]

#212228

FromÉtienne Mollier <etienne.mollier@mailoo.org>
Date2019-08-04 11:50 +0200
Message-ID<yrljj-5WI-3@gated-at.bofh.it>
In reply to#212226

[Multipart message — attachments visible in raw view] — view raw

Long Wind, on 2019-08-04:
> i enter "df -h"
> Filesystem      Size  Used Avail Use% Mounted on
> [...]
> /dev/sda2       9.8G  9.3G     0 100% /
> ......
>
> 0.5 G seems missing

This space is most likely taken up by file system metadata, such
as inode tables, or journaling space.  0.5 G looks a lot like 5%
of a 10 G partition, which is the default setting for Ext4
metadata as provided in Debian Installer.

Kind Regards
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d

[toc] | [prev] | [next] | [standalone]

#212231

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2019-08-04 12:00 +0200
Message-ID<yrlt0-60g-7@gated-at.bofh.it>
In reply to#212228

[Multipart message — attachments visible in raw view] — view raw

On Du, 04 aug 19, 11:46:31, Étienne Mollier wrote:
> 
> This space is most likely taken up by file system metadata, such
> as inode tables, or journaling space.  0.5 G looks a lot like 5%
> of a 10 G partition, which is the default setting for Ext4
> metadata as provided in Debian Installer.

The 5% are "reserved for the super-user", not metadata, see the manpage 
for mke2fs.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#212232

FromÉtienne Mollier <etienne.mollier@mailoo.org>
Date2019-08-04 12:30 +0200
Message-ID<yrlW1-6pt-7@gated-at.bofh.it>
In reply to#212231

[Multipart message — attachments visible in raw view] — view raw

On 04/08/2019 11.58, Andrei POPESCU wrote:
> On Du, 04 aug 19, 11:46:31, Étienne Mollier wrote:
>> This space is most likely taken up by file system metadata, such
>> as inode tables, or journaling space.  0.5 G looks a lot like 5%
>> of a 10 G partition, which is the default setting for Ext4
>> metadata as provided in Debian Installer.
> The 5% are "reserved for the super-user", not metadata, see the manpage 
> for mke2fs.

My bad, I shouldn't intervene from memory like this.  Now you
mention it, I recall it's also worded this way in d-i too.

Thanks,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

[toc] | [prev] | [next] | [standalone]

#212230

From"Thomas Schmitt" <scdbackup@gmx.net>
Date2019-08-04 12:00 +0200
Message-ID<yrlsZ-60g-5@gated-at.bofh.it>
In reply to#212226
Hi,

Long Wind wrote:
> /dev/sda2       9.8G  9.3G     0 100% /

I place my bet on the highest rated answer in
  https://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why
mattdm wrote there:
  "Ext3 is pretty good at avoiding filesystem fragmentation, but once
   you get above about 95% full, that behavior falls off the cliff,
   and suddenly filesystem performance becomes a mess. So leaving 5%
   reserved gives you a buffer against this."


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#212233

From<tomas@tuxteam.de>
Date2019-08-04 12:30 +0200
Message-ID<yrlW1-6pt-5@gated-at.bofh.it>
In reply to#212226

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 04, 2019 at 09:37:12AM +0000, Long Wind wrote:
>  thank!  i enter "du -sh /home", it's 5.8G. it's unbelievable

You mean: it is more than you expected? If so, you can try

  du -sh /home/*

to see which subdirectory holds the biggest chunk, and slowly
work your way down the directory tree (note: this will exclude
the dot files and directories, because the glob ("*") doesn't
include them, at least usually. If you suspect one of those,
better do

  du -sh $(ls -A /home)

or something similar)

> i enter "df -h"Filesystem      Size  Used Avail Use% Mounted on
> udev            1.5G     0  1.5G   0% /dev
> tmpfs           298M  4.5M  293M   2% /run
> /dev/sda2       9.8G  9.3G     0 100% /......
> 
> 0.5 G seems missing

Others have chimed in with good ideas. First, 0.5G seems reasonable
for "file system internal use" -- inodes, possibly journal, etc.

On my box:

  tomas@trotzki:~$ sudo du -sh /home
  [sudo] password for tomas: 
  368G    /home
  
  tomas@trotzki:~$ df -h
  Filesystem                Size  Used Avail Use% Mounted on
  [...]
  /dev/mapper/trotzki-home  640G  368G  241G  61% /home

That's (368 - 241) / 368 -- around 35 percent (it's an ext4 file system).

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#212234

FromLong Wind <longwind2@yahoo.com>
Date2019-08-04 12:50 +0200
Message-ID<yrmfn-6ws-5@gated-at.bofh.it>
In reply to#212233

[Multipart message — attachments visible in raw view] — view raw

 i think i find outit's in ~/.local it's Xorg.0.log.oldit's more than 3.9Git seems keeping growingclearly i don't need it, i delete it
it should solve my problem
Thanks to all that reply!

    On Sunday, August 4, 2019, 6:26:11 PM GMT+8, tomas@tuxteam.de <tomas@tuxteam.de> wrote:  
 
 On Sun, Aug 04, 2019 at 09:37:12AM +0000, Long Wind wrote:
>  thank!  i enter "du -sh /home", it's 5.8G. it's unbelievable

You mean: it is more than you expected? If so, you can try

  du -sh /home/*

to see which subdirectory holds the biggest chunk, and slowly
work your way down the directory tree (note: this will exclude
the dot files and directories, because the glob ("*") doesn't
include them, at least usually. If you suspect one of those,
better do

  du -sh $(ls -A /home)

or something similar)

> i enter "df -h"Filesystem      Size  Used Avail Use% Mounted on
> udev            1.5G     0  1.5G   0% /dev
> tmpfs           298M  4.5M  293M   2% /run
> /dev/sda2       9.8G  9.3G     0 100% /......
> 
> 0.5 G seems missing

Others have chimed in with good ideas. First, 0.5G seems reasonable
for "file system internal use" -- inodes, possibly journal, etc.

On my box:

  tomas@trotzki:~$ sudo du -sh /home
  [sudo] password for tomas: 
  368G    /home
  
  tomas@trotzki:~$ df -h
  Filesystem                Size  Used Avail Use% Mounted on
  [...]
  /dev/mapper/trotzki-home  640G  368G  241G  61% /home

That's (368 - 241) / 368 -- around 35 percent (it's an ext4 file system).

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#212235

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2019-08-04 13:10 +0200
Message-ID<yrmyJ-6SR-7@gated-at.bofh.it>
In reply to#212234
Le 04/08/2019 à 12:43, Long Wind a écrit :
> i think i find out
> it's in ~/.local it's Xorg.0.log.old
> it's more than 3.9G
> it seems keeping growing
> clearly i don't need it, i delete it
> it should solve my problem

What about Xorg.0.log ?
If these files keep growing up to such a size, then it means that they 
are flooded by repeated messages. Before deleting them, you should read 
their contents and fix the underlying issue or they will fill your disk 
space again and again.

[toc] | [prev] | [next] | [standalone]

#212240

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2019-08-04 17:40 +0200
Message-ID<yrqM2-Za-21@gated-at.bofh.it>
In reply to#212235
On Sun 04 Aug 2019 at 13:06:07 (+0200), Pascal Hambourg wrote:
> Le 04/08/2019 à 12:43, Long Wind a écrit :
> > i think i find out
> > it's in ~/.local it's Xorg.0.log.old
> > it's more than 3.9G
> > it seems keeping growing
> > clearly i don't need it, i delete it
> > it should solve my problem
> 
> What about Xorg.0.log ?
> If these files keep growing up to such a size, then it means that they
> are flooded by repeated messages. Before deleting them, you should
> read their contents and fix the underlying issue or they will fill
> your disk space again and again.

Agreed. It would be odd if Xorg.0.log.old is still growing because
that's the log from the previous session. So I'd assume it's
probably Xorg.0.log that's growing, and Xorg.0.log.old is just
sitting there.

Bear in mind that if you delete a file that is still held open by
some process, you won't reclaim the free space until that process
closes the file. So until that time, du will no longer see its
space as used but df will not see it as available either.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212245

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2019-08-04 23:40 +0200
Message-ID<yrwop-4xP-1@gated-at.bofh.it>
In reply to#212240
Le 04/08/2019 à 22:56, Long Wind a écrit :
>   the file is more than 3 G, i can't read it with nanoi have 3 G memory, no swap

You do not use an *editor* to *read* a file, you use a pager such as 
more, less, most...

> why don't X print important error msg to terminals?i can't see any of them
> 
> is it a bug of X?? my problem isn't solved,
> ls .local/share/xorg/ -ltotal 3770920
> -rw-r--r-- 1 zhou zhou      32654 Aug  5 04:40 Xorg.0.log
> -rw-r--r-- 1 zhou zhou      39127 Aug  5 04:38 Xorg.0.log.old
> -rw-r--r-- 1 zhou zhou 3861332996 Aug  4 22:16 Xorg.1.log
> 
> below is Xorg.0.log:

This one is normal.

[toc] | [prev] | [next] | [standalone]

#212253

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2019-08-05 06:10 +0200
Message-ID<yrCtP-5n-1@gated-at.bofh.it>
In reply to#212240
On Sun 04 Aug 2019 at 20:56:01 (+0000), Long Wind wrote:
>  the file is more than 3 G, i can't read it with nanoi have 3 G memory, no swap
> why don't X print important error msg to terminals?i can't see any of them
> 
> is it a bug of X?? my problem isn't solved, 
> ls .local/share/xorg/ -ltotal 3770920
> -rw-r--r-- 1 zhou zhou      32654 Aug  5 04:40 Xorg.0.log
> -rw-r--r-- 1 zhou zhou      39127 Aug  5 04:38 Xorg.0.log.old
> -rw-r--r-- 1 zhou zhou 3861332996 Aug  4 22:16 Xorg.1.log

You reported Sun, 4 Aug 2019 10:43:06 +0000 (UTC) that:
    Xorg.0.log.old
    it's more than 3.9G
    it seems keeping growing
    clearly i don't need it,
    i delete it

Since then it would appear that you've run X twice, so any Xorg.0.log*
files from that era have long gone. But now you've sprung the file
Xorg.1.log on us, which looks as though you've run 2 X servers at the
same time, just on the one occasion, the evening of 2019-08-04.
(But I don't know whether you timezone is really UTC.)

I'm guessing that whatever made Xorg.0.log huge also had the same
effect on Xorg.1.log so it would be useful to look at that file
before you delete it.
$ tail -100 ~/.local/share/xorg/Xorg.1.log
will show you the last 100 lines which might be enough. If not,
you can sample the file with
$ less ~/.local/share/xorg/Xorg.1.log
and then by typing   50p   70p   90p   95p   which will move to 50%,
70%, 90%, 95% of the way through the file, faster than scrolling.

It's quite possible that the files' sizes were entirely caused by
your running two X servers at the same time. The log may tell
you what the issue was, and it would be useful to post it
(the issue, and perhaps a few lines from the log) here.

> below is Xorg.0.log:

[snipped]

> On Sunday, August 4, 2019, 11:37:07 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:  
>  On Sun 04 Aug 2019 at 13:06:07 (+0200), Pascal Hambourg wrote:
> > Le 04/08/2019 à 12:43, Long Wind a écrit :
> > > i think i find out
> > > it's in ~/.local it's Xorg.0.log.old
> > > it's more than 3.9G
> > > it seems keeping growing
> > > clearly i don't need it, i delete it
> > > it should solve my problem
> > 
> > What about Xorg.0.log ?
> > If these files keep growing up to such a size, then it means that they
> > are flooded by repeated messages. Before deleting them, you should
> > read their contents and fix the underlying issue or they will fill
> > your disk space again and again.
> 
> Agreed. It would be odd if Xorg.0.log.old is still growing because
> that's the log from the previous session. So I'd assume it's
> probably Xorg.0.log that's growing, and Xorg.0.log.old is just
> sitting there.
> 
> Bear in mind that if you delete a file that is still held open by
> some process, you won't reclaim the free space until that process
> closes the file. So until that time, du will no longer see its
> space as used but df will not see it as available either.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212254

FromLong Wind <longwind2@yahoo.com>
Date2019-08-05 06:20 +0200
Message-ID<yrCDv-9C-1@gated-at.bofh.it>
In reply to#212253

[Multipart message — attachments visible in raw view] — view raw

 Thank David!it seems it's bug of X
 tail -100 .local/share/xorg/Xorg.1.log 

[ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values

......

    On Monday, August 5, 2019, 12:07:30 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:  
 
 On Sun 04 Aug 2019 at 20:56:01 (+0000), Long Wind wrote:
>  the file is more than 3 G, i can't read it with nanoi have 3 G memory, no swap
> why don't X print important error msg to terminals?i can't see any of them
> 
> is it a bug of X?? my problem isn't solved, 
> ls .local/share/xorg/ -ltotal 3770920
> -rw-r--r-- 1 zhou zhou      32654 Aug  5 04:40 Xorg.0.log
> -rw-r--r-- 1 zhou zhou      39127 Aug  5 04:38 Xorg.0.log.old
> -rw-r--r-- 1 zhou zhou 3861332996 Aug  4 22:16 Xorg.1.log

You reported Sun, 4 Aug 2019 10:43:06 +0000 (UTC) that:
    Xorg.0.log.old
    it's more than 3.9G
    it seems keeping growing
    clearly i don't need it,
    i delete it

Since then it would appear that you've run X twice, so any Xorg.0.log*
files from that era have long gone. But now you've sprung the file
Xorg.1.log on us, which looks as though you've run 2 X servers at the
same time, just on the one occasion, the evening of 2019-08-04.
(But I don't know whether you timezone is really UTC.)

I'm guessing that whatever made Xorg.0.log huge also had the same
effect on Xorg.1.log so it would be useful to look at that file
before you delete it.
$ tail -100 ~/.local/share/xorg/Xorg.1.log
will show you the last 100 lines which might be enough. If not,
you can sample the file with
$ less ~/.local/share/xorg/Xorg.1.log
and then by typing  50p  70p  90p  95p  which will move to 50%,
70%, 90%, 95% of the way through the file, faster than scrolling.

It's quite possible that the files' sizes were entirely caused by
your running two X servers at the same time. The log may tell
you what the issue was, and it would be useful to post it
(the issue, and perhaps a few lines from the log) here.

> below is Xorg.0.log:

[snipped]

> On Sunday, August 4, 2019, 11:37:07 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:  
>  On Sun 04 Aug 2019 at 13:06:07 (+0200), Pascal Hambourg wrote:
> > Le 04/08/2019 à 12:43, Long Wind a écrit :
> > > i think i find out
> > > it's in ~/.local it's Xorg.0.log.old
> > > it's more than 3.9G
> > > it seems keeping growing
> > > clearly i don't need it, i delete it
> > > it should solve my problem
> > 
> > What about Xorg.0.log ?
> > If these files keep growing up to such a size, then it means that they
> > are flooded by repeated messages. Before deleting them, you should
> > read their contents and fix the underlying issue or they will fill
> > your disk space again and again.
> 
> Agreed. It would be odd if Xorg.0.log.old is still growing because
> that's the log from the previous session. So I'd assume it's
> probably Xorg.0.log that's growing, and Xorg.0.log.old is just
> sitting there.
> 
> Bear in mind that if you delete a file that is still held open by
> some process, you won't reclaim the free space until that process
> closes the file. So until that time, du will no longer see its
> space as used but df will not see it as available either.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212266

Fromdavidson <davidson@freevolt.org>
Date2019-08-05 18:10 +0200
Message-ID<yrNIB-74h-1@gated-at.bofh.it>
In reply to#212254

[Multipart message — attachments visible in raw view] — view raw

On Mon, 5 Aug 2019, Long Wind wrote:

> Thank David!it seems it's bug of X
>  tail -100 .local/share/xorg/Xorg.1.log

To me it looks like the log below is telling you that your power key
was either being held down or stuck in that position.

That is all.

>
> [ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 21261.466] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
>
> ......
>
>    On Monday, August 5, 2019, 12:07:30 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:
>
> On Sun 04 Aug 2019 at 20:56:01 (+0000), Long Wind wrote:
>>   the file is more than 3 G, i can't read it with nanoi have 3 G memory, no swap
>> why don't X print important error msg to terminals?i can't see any of them
>>
>> is it a bug of X?? my problem isn't solved,
>> ls .local/share/xorg/ -ltotal 3770920
>> -rw-r--r-- 1 zhou zhou      32654 Aug  5 04:40 Xorg.0.log
>> -rw-r--r-- 1 zhou zhou      39127 Aug  5 04:38 Xorg.0.log.old
>> -rw-r--r-- 1 zhou zhou 3861332996 Aug  4 22:16 Xorg.1.log
>
> You reported Sun, 4 Aug 2019 10:43:06 +0000 (UTC) that:
>     Xorg.0.log.old
>     it's more than 3.9G
>     it seems keeping growing
>     clearly i don't need it,
>     i delete it
>
> Since then it would appear that you've run X twice, so any Xorg.0.log*
> files from that era have long gone. But now you've sprung the file
> Xorg.1.log on us, which looks as though you've run 2 X servers at the
> same time, just on the one occasion, the evening of 2019-08-04.
> (But I don't know whether you timezone is really UTC.)
>
> I'm guessing that whatever made Xorg.0.log huge also had the same
> effect on Xorg.1.log so it would be useful to look at that file
> before you delete it.
> $ tail -100 ~/.local/share/xorg/Xorg.1.log
> will show you the last 100 lines which might be enough. If not,
> you can sample the file with
> $ less ~/.local/share/xorg/Xorg.1.log
> and then by typing  50p  70p  90p  95p  which will move to 50%,
> 70%, 90%, 95% of the way through the file, faster than scrolling.
>
> It's quite possible that the files' sizes were entirely caused by
> your running two X servers at the same time. The log may tell
> you what the issue was, and it would be useful to post it
> (the issue, and perhaps a few lines from the log) here.
>
>> below is Xorg.0.log:
>
> [snipped]
>
>> On Sunday, August 4, 2019, 11:37:07 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote: 
>>   On Sun 04 Aug 2019 at 13:06:07 (+0200), Pascal Hambourg wrote:
>>> Le 04/08/2019 à 12:43, Long Wind a écrit :
>>>> i think i find out
>>>> it's in ~/.local it's Xorg.0.log.old
>>>> it's more than 3.9G
>>>> it seems keeping growing
>>>> clearly i don't need it, i delete it
>>>> it should solve my problem
>>>
>>> What about Xorg.0.log ?
>>> If these files keep growing up to such a size, then it means that they
>>> are flooded by repeated messages. Before deleting them, you should
>>> read their contents and fix the underlying issue or they will fill
>>> your disk space again and again.
>>
>> Agreed. It would be odd if Xorg.0.log.old is still growing because
>> that's the log from the previous session. So I'd assume it's
>> probably Xorg.0.log that's growing, and Xorg.0.log.old is just
>> sitting there.
>>
>> Bear in mind that if you delete a file that is still held open by
>> some process, you won't reclaim the free space until that process
>> closes the file. So until that time, du will no longer see its
>> space as used but df will not see it as available either.
>
> Cheers,
> David.
>
>

-- 
  The day will come              |  Last words, August Spies (1855--1887).
  When our silence will be       |  Hanged, by the U.S. state of Illinois,
  More powerful than             |  alongside fellow journalists
  The voices you strangle today  |  Adolf Fischer and Albert Parsons.

[toc] | [prev] | [next] | [standalone]

#212267

FromCurt <curty@free.fr>
Date2019-08-05 18:40 +0200
Message-ID<yrObD-7et-11@gated-at.bofh.it>
In reply to#212266
On 2019-08-05, davidson <davidson@freevolt.org> wrote:
>
> To me it looks like the log below is telling you that your power key
> was either being held down or stuck in that position.
>
> That is all.

Whatever libinput is trying to say is apparently repeated to the point
where I would consider the repetition itself to be a form of bug,
whether the power key is going haywire or not (which Long doesn't
mention as a vector of particular concern).

So if the power key goose is wild (or "fixing" the incriminated key is
impractical for one reason or another), how do we get libinput to shut
its redundant trap?

>>
>> [ 21261.465] (EE) libinput bug: Key count for KEY_POWER reached abnormal values


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

[toc] | [prev] | [next] | [standalone]

#212284

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2019-08-06 02:10 +0200
Message-ID<yrVd8-3mY-3@gated-at.bofh.it>
In reply to#212267
On Mon 05 Aug 2019 at 16:33:29 (-0000), Curt wrote:
> On 2019-08-05, davidson <davidson@freevolt.org> wrote:
> >
> > To me it looks like the log below is telling you that your power key
> > was either being held down or stuck in that position.
> >
> > That is all.
> 
> Whatever libinput is trying to say is apparently repeated to the point
> where I would consider the repetition itself to be a form of bug,
> whether the power key is going haywire or not (which Long doesn't
> mention as a vector of particular concern).

#define KEY_POWER     	 116	    /* SC System Power Down */

doesn't give me much of a clue as to what sort of power key this is,
but from the company is keeps I'd guess it might be for powering
down a Sound Card. We know the OP watches TV through a sound card,
and has wished to shut it up when the computer is switched off.
Perhaps it's something to do with that.

As for key repetition: the OP has communicated here on this topic
before. Could the problem be self-inflicted: it wouldn't necessarily
be noticed if only Xorg.0.log grew, because restarting X would clean
the directory of all but two generations. However, that third file,
Xorg.1.log, is not going to get cleaned until a second simultaneous
X server has been run twice. The lack of any Xorg.1.log.old suggests
that this is not the OP's habit.

> So if the power key goose is wild (or "fixing" the incriminated key is
> impractical for one reason or another), how do we get libinput to shut
> its redundant trap?

That depends. If you can't restart X because of what's running, one
method might be to chattr +i, though that leaves a large file in
place which might mean moving things around to make room.

If the problem keeps recurring, but you don't want to have to fix it
in haste, then you could try linking ~/.local/share/xorg to a small
spare partition that you can allow to fill up. If you're running
Xserver as root, you can set -logfile there instead.

You might try experimenting with -logverbose which defaults to 3.
No idea what range of values might be allowed or suitable.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212669

FromLong Wind <longwind2@yahoo.com>
Date2019-08-12 10:00 +0200
Message-ID<yudpi-1o2-51@gated-at.bofh.it>
In reply to#212284

[Multipart message — attachments visible in raw view] — view raw

 
for reason i don't know, i see your reply just an hour ago, sorry for delay! 

i'm not sure if power key is key on keyboard or button on PC case
i'm afraid the bug not only use all disk, but also take cpu resource, it slow system
i'm not energetic enough to debug it
i have other choice, i have buster, jessie, stretch on another disk that seems ok

i hope info below help

tail -100 /mnt/dos/home/zhou/.local/share/xorg/Xorg.0.log.old
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.015] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.016] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.018] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.019] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.020] (**) Option "fd" "31"
[ 726.021] (EE) libinput bug: Key 116 is down 75 times.
[ 726.021] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[ 726.021] (EE) libinput bug: Releasing key 116 failed.
[ 726.023] (**) Option "fd" "26"
[ 726.033] (**) Option "fd" "28"
[ 726.034] (**) Option "fd" "30"
[ 726.132] (II) UnloadModule: "libinput"
[ 726.132] (II) systemd-logind: not releasing fd for 13:69, still in use
[ 726.132] (II) UnloadModule: "libinput"
[ 726.132] (II) systemd-logind: not releasing fd for 13:65, still in use
[ 726.132] (II) UnloadModule: "libinput"
[ 726.132] (II) systemd-logind: not releasing fd for 13:67, still in use
[ 726.132] (II) UnloadModule: "libinput"
[ 726.132] (II) systemd-logind: releasing fd for 13:73
[ 726.364] (II) UnloadModule: "libinput"
[ 726.364] (II) systemd-logind: releasing fd for 13:69
[ 726.364] (EE) systemd-logind: failed to release device: Connection was disconnected before a reply was received
[ 726.364] (II) UnloadModule: "libinput"
[ 726.364] (II) systemd-logind: releasing fd for 13:68
[ 726.364] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.364] (II) UnloadModule: "libinput"
[ 726.364] (II) systemd-logind: releasing fd for 13:65
[ 726.364] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.365] (II) UnloadModule: "libinput"
[ 726.365] (II) systemd-logind: releasing fd for 13:64
[ 726.365] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.365] (II) UnloadModule: "libinput"
[ 726.365] (II) systemd-logind: releasing fd for 13:67
[ 726.365] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.365] (II) UnloadModule: "libinput"
[ 726.365] (II) systemd-logind: releasing fd for 13:66
[ 726.365] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.365] (II) UnloadModule: "libinput"
[ 726.365] (II) systemd-logind: releasing fd for 13:70
[ 726.365] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.365] (II) UnloadModule: "libinput"
[ 726.365] (II) systemd-logind: releasing fd for 13:71
[ 726.365] (EE) systemd-logind: failed to release device: Connection is closed
[ 726.373] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[ 726.373] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
[ 726.373] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error
[ 726.373] (EE) systemd-logind: ReleaseControl failed: Connection is closed
[ 726.373] (II) Server terminated successfully (0). Closing log file.



     On Tuesday, August 6, 2019, 8:04:32 AM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:  
 
 On Mon 05 Aug 2019 at 16:33:29 (-0000), Curt wrote:
> On 2019-08-05, davidson <davidson@freevolt.org> wrote:
> >
> > To me it looks like the log below is telling you that your power key
> > was either being held down or stuck in that position.
> >
> > That is all.
> 
> Whatever libinput is trying to say is apparently repeated to the point
> where I would consider the repetition itself to be a form of bug,
> whether the power key is going haywire or not (which Long doesn't
> mention as a vector of particular concern).

#define KEY_POWER        116        /* SC System Power Down */

doesn't give me much of a clue as to what sort of power key this is,
but from the company is keeps I'd guess it might be for powering
down a Sound Card. We know the OP watches TV through a sound card,
and has wished to shut it up when the computer is switched off.
Perhaps it's something to do with that.

As for key repetition: the OP has communicated here on this topic
before. Could the problem be self-inflicted: it wouldn't necessarily
be noticed if only Xorg.0.log grew, because restarting X would clean
the directory of all but two generations. However, that third file,
Xorg.1.log, is not going to get cleaned until a second simultaneous
X server has been run twice. The lack of any Xorg.1.log.old suggests
that this is not the OP's habit.

> So if the power key goose is wild (or "fixing" the incriminated key is
> impractical for one reason or another), how do we get libinput to shut
> its redundant trap?

That depends. If you can't restart X because of what's running, one
method might be to chattr +i, though that leaves a large file in
place which might mean moving things around to make room.

If the problem keeps recurring, but you don't want to have to fix it
in haste, then you could try linking ~/.local/share/xorg to a small
spare partition that you can allow to fill up. If you're running
Xserver as root, you can set -logfile there instead.

You might try experimenting with -logverbose which defaults to 3.
No idea what range of values might be allowed or suitable.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212693

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2019-08-12 16:50 +0200
Message-ID<yujO1-5wq-1@gated-at.bofh.it>
In reply to#212669
On Mon 12 Aug 2019 at 07:59:03 (+0000), Long Wind wrote:
>  
> for reason i don't know, i see your reply just an hour ago, sorry for delay! 
> 
> i'm not sure if power key is key on keyboard or button on PC case

If the one on the PC case got stuck, I would expect the machine to
power down. So look for a key on the keyboard. As I said, I can only
guess that it powers down the Sound Card, perhaps to save energy.

> i'm afraid the bug not only use all disk, but also take cpu resource, it slow system
> i'm not energetic enough to debug it
> i have other choice, i have buster, jessie, stretch on another disk that seems ok
> 
> i hope info below help

It confirms what you posted before. Swapping keyboards may be helpful
in diagnosing the cause. It might be the only solution too. Otherwise,
I can only reiterate my suggestions for masking the symptoms.

> tail -100 /mnt/dos/home/zhou/.local/share/xorg/Xorg.0.log.old
> [ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[…]
> [ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 726.020] (**) Option "fd" "31"
> [ 726.021] (EE) libinput bug: Key 116 is down 75 times.
> [ 726.021] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 726.021] (EE) libinput bug: Releasing key 116 failed.

116 agrees with KEY_POWER in the source file.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#212718

FromLong Wind <longwind2@yahoo.com>
Date2019-08-13 01:00 +0200
Message-ID<yursg-1Uo-7@gated-at.bofh.it>
In reply to#212693

[Multipart message — attachments visible in raw view] — view raw

 
i don't think swapping keyboard will help
i use buster/jessie with same keyboard, it's OK
as log shows, problem is with software, not with my hardware 
easy solution for me is install buster over it.

many of list mail go to spam folder of yahoo mail
that may explain why i can't read mail on time
     On Monday, August 12, 2019, 10:42:02 PM GMT+8, David Wright <deblis@lionunicorn.co.uk> wrote:  
 
 On Mon 12 Aug 2019 at 07:59:03 (+0000), Long Wind wrote:
>  
> for reason i don't know, i see your reply just an hour ago, sorry for delay! 
> 
> i'm not sure if power key is key on keyboard or button on PC case

If the one on the PC case got stuck, I would expect the machine to
power down. So look for a key on the keyboard. As I said, I can only
guess that it powers down the Sound Card, perhaps to save energy.

> i'm afraid the bug not only use all disk, but also take cpu resource, it slow system
> i'm not energetic enough to debug it
> i have other choice, i have buster, jessie, stretch on another disk that seems ok
> 
> i hope info below help

It confirms what you posted before. Swapping keyboards may be helpful
in diagnosing the cause. It might be the only solution too. Otherwise,
I can only reiterate my suggestions for masking the symptoms.

> tail -100 /mnt/dos/home/zhou/.local/share/xorg/Xorg.0.log.old
> [ 726.014] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
[…]
> [ 726.020] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 726.020] (**) Option "fd" "31"
> [ 726.021] (EE) libinput bug: Key 116 is down 75 times.
> [ 726.021] (EE) libinput bug: Key count for KEY_POWER reached abnormal values
> [ 726.021] (EE) libinput bug: Releasing key 116 failed.

116 agrees with KEY_POWER in the source file.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web