Lots of programs have seemingly random problems whenever they are run on a machine which is running out of disk space.  These problems are often hard to debug and troubleshoot.

So my suggestion is to include the free disk space (from most mounted drives) in the system information that's automatically added to bug reports.

Perhaps doing something like:

  df | grep "^/dev/[sh]d"

That way, package maintainers can easily check that when they are confronted with a weird problem.

Francois

Hi Francois,

On 07/07/18 00:09 +1200, Francois Marier said ...

Package maintainers who often face problems with reports and/or help
requests that involve lack of disk space, should probably use the hooks
to reportbug via /usr/share/bug/<package>/script to achieve this :)  See
/usr/share/doc/reportbug/README.developers for details.

Adding the above information to all bug reports probably doesn't make
sense.  If this sounds reasonable, we can mark this bug as wontfix.

Cheers,

Giridhar

Thanks for pointing this out.

Well, my main point is that a lot of package maintainers, I suspect, may not
know exactly how their packages behave with a full disk. I, for one,
wouldn't know which packages to add this check in.  So I would probably end
up adding it to all of them.  I suspect that a lot of my packages would fail
in mysterious ways if the root partition was full.

I guess this bug report is about whether or not it makes sense to make this
the default.  I think it does because a full root partition is likely to
make any package fail.  At least I think we could show the free disk space
in the root partition (perhaps only show it if it's below a certain
threshold).  Something like:

  Root partition has only 10 MB left of free space.

Doing that way, with a threshold would reduce the clutter in bug reports,
but still display a piece of information that could be very useful.

What do you think?

Francois

Hi all,
in bug #433462 there is a request to add free space information in
reportbug standard info appended to bug report.

It's a valid request, that I want to fulfill, but there are some
aspects I'd like to discuss.

First of all, with your package maintainers hat on, what kind of
information you'd like? only the value of free MB in the disk? total
size, free size? also percentage? I think that from a bug report
point-of-view, only the free megabytes value would do.

That said, what to report? Simply taking the output of "df -h" and
attaching to reportbug template it's not what I like: there could be
more partitions/disks not interesting for the report/system in that
output, and I don't want to include them.

So I thought: "Easy, just take the information for / and add them".
Well, not really. There are situation where /usr, /var, /etc and/or
many more directories are in separate partitions, and it might be
interesting to include those information too (if not with /). But, how
further should I go? Just take / and /usr, /var, /etc if-not-in-/ and
add them? what if /var has subdirs like /var/log /var/tmp /var/lib
splitted in different partition? what if /usr has /usr/bin and
/usr/share on a NFS filer?

So, just to recap:

- what free space information you'd like? (I'd propose only the count
of free MB)
- what directory to show in the report? (I'd propose /, /var, /usr,
/etc if the latter 3 not in / but not going recursively under them)

Thanks for your attention,
Sandro

PS: please keep the bug in CC, so that there will he history of the
discussion there too.

Imho you need to show the directories where the program would need to
write. So /tmp, /var, /home (hmhmh...), stuff like that.

I'm not sure /etc and /usr are valid here, except in few cases (like
when upgrading packages).

Cheers,

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.general as well.

[Sandro Tosi]

I would suggest to include all directories relevant for the package at
hand.  Look at the file list for the package, and report all
partitions touched by the package, as well as /tmp/ and /var/lib/dpkg/
if those are on separate partitions.

Happy hacking,

The main thing that you'd care about is being able to answer whether
or not free space or free inodes is likely to be a culprit, so you can
triage bugs.

In almost all cases, if there's more than a gigabyte of free space (or
say, more than 10% free) and more than a few thousand free inodes (or
say, more than %30 free), disk space shouldn't be an issue, and no one
cares about those devices. Outputting them just makes the report more
verbose. [Just a "free space/inodes seem ok" line would be enough.]

Otherwise, reportbug can prompt to include partitions which might
actually have a problem. [Here, only the mount points, free space, and
free indoes matter, and anything mounted in deeper directories
(ignoring/var or /usr) can probably have the mount point obfuscated.


Don Armstrong

Do not forget quota please

Bastien

Sandro Tosi <morph@debian.org> writes:
it should give a meaningfull error message. An error message containing
the location and "No space left on device" should be sufficiently
obvious to either the reportee or maintainer to diagnose the problem
without any free space information.

On the other hand including free space information will be difficult to
handle properly and possibly expose information the user considers
private.


But if you do go ahead with this consider this:

The bugreport gives the following argument: "I suspect that a lot of my
packages would fail in mysterious ways if the root partition was full."
How will his software behave with the root partition being mounted
read-only? Listing the free space on root or /usr would be completly
meaningless if they are read-only and writing to them would be a
critical bug anyway.

The only places where a normal application should write to are /tmp and
$HOME. Those could be included by default. Some packages (daemons
mostly) could further need /var/. But I would think most packages would
not be interested in that. Any other place I would think is completly
application specific and should be included only on the applications
request.

MfG
        Goswin

Add also quota information if available