I was thinking about having the programs that start on login output their stdout/stderr to files, so I can check the stdout/stderr for any of them if necessary. I also plan to overwrite the last log file instead of appending.

Are there any negative side effects to doing this? My specific concern is unnecessary hard drive activity.

  • 3
    If you need the logs, then the HD activity is hardly unnecessary, is it?
    – Mat
    Nov 30 '13 at 9:20

If you aren't careful about how much logging output your program generates, you can still fill up a disk despite not creating more than one log file, causing all kinds of problems:

  1. If run as root, you can literally fill the disk, since that bypasses quotas. Some filesystems also reserve a certain minimum amount of free space for root, to avoid the below problems.

  2. If a filesystem is full, you can't even create a temporary file on the disk. If the filesystem you fill is also where some of your common temp space lives (/tmp, /usr/tmp, /var/tmp) programs trying to use that space will likely die if running or fail to start if not.

  3. Programs that crash when this happens won't drop cores, if you've set your system up to allow this. That can make it difficult to reduce those programs' sensitivity to low-disk-space conditions, since it makes it harder to discover the specific code path that crashed the program.

You can run logrotate along with your program to mitigate the risk of this.

logrotate isn't 100% foolproof. It typically runs as a cron job, so if you fill the disk between two cron runs, the problem won't be corrected until logrotate next runs.


stderr should already be logged to .xsession-errors, at least on some Linux distributions.

Of course I am assuming you are solely talking about graphical logins.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy