| Summary: | kde erraneously refuses to start due to insufficient space on /tmp | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | gunther.clasen |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cfeck |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
This check is no longer in the startkde script in KDE 4. |
Version: unspecified (using KDE 1.2) OS: Linux startkde can refuse to start kde due to insufficient space on /tmp even though /tmp has plenty of space available. Noticed problem in # DEFAULT KDE STARTUP SCRIPT ( KDE-3.3.1 ) but also present in # DEFAULT KDE STARTUP SCRIPT ( KDE-3.5.4 ) and possibly later versions. Reproducible: Sometimes Steps to Reproduce: The df command in the script evaluates BLCOK_SIZE, which is unset in the script before df is being used. This is correct. However, df (now) also evaluates DF_BLOCK_SIZE, which is not unset in the script. If DF_BLOCK_SIZE is set to a high value (e.g. GB) then startkde will fail, thinking it has only a few KB on /tmp when in fact is has a few GB. The same for $HOME Expected Results: I expect startkde to start kde if DF_BLOCK_SIZE is set to GB and /tmp has 4GB free space. It is more reliable to explicitly set the block size. Here is a patch which works: 13,14c13,14 < space_tmp=`LANG=C df /tmp | xargs | cut -d" " -f11` < homedir_mount=`LANG=C df "$HOME" | xargs | cut -d" " -f8` --- > space_tmp=`LANG=C df -k /tmp | xargs | cut -d" " -f11` > homedir_mount=`LANG=C df -k "$HOME" | xargs | cut -d" " -f8`