how to response the request to add more space?

[Hanry Zhou]

My customer run into the problem to execute his application script, and got error like "can't write to a file". They got same error last time, and the previous SA extended 2 file systems, and the error is gone.

Now, this time, the file systems they suspect with have the space of 2Gb, and 900mb(/tmp), I believe should be big enough, however, they still ask me to increase the /tmp.

Other than the error message, they don't have any thing else to be sure it is space problem.

I don't think it is right way to approach the problem. From SA point of view, what is approproate response or approach to looking into the issue?

[curt larson_1 · Accepted solution]

you could ask them for the time this occured?
there should be log entry telling which file system was full and when that occured. you should be able to match the log entry to when their error occured.

and having the error message is only part of the information needed by you. The most important part is "what were you doing" that caused the error message. And, can you reproduce their error by doing the same thing.

that is a start to correcting the issue.

[John Poff]

Hi,

You can check the syslog log file and see if it has any entries complaining about running out of disk space. If you don't see any complaints there, it might suggest that they have another problem, such as file/directory permissions, or having too many open files. I would also try to steer them towards using /var/tmp for temp files instead of /tmp.

JP

[A. Clay Stephenson]

1) Ask them if they adhere to the TMPDIR standard. In that case, their temp files could go anywhere. 2) Because they are writing to /tmp instead of /var/tmp, I strongly suspect that they do not use the TMPDIR enviroment variable and thus may not be the guys I would want doing my coding. 3) In any event, in the modern UNIX world, application do not write to /tmp which is reserved for the OS but instead should use /var/tmp.

[Hanry Zhou]

the space they wanted most is on /tmp, but it's alerady > 900mb, so, I don't believe that would be the cause.

I know it could be file/dir permissions, and too many files opened, which I've already told them, but they still insist on requeting of adding more space.

I checked syslog.log, and don't see any message like fs full, or anthing possibly caused the problem.

what I should ask them to check out, specifically, and should I as SA do what they asked under this cicumstances?

[John Kittel]

Find out if the application is just continually adding new files to the filesystems, and never deleting them. If so, fix the application to delete files when it is done with them, or write a cron job to do so.

- John

[John Poff]

I would ask them for a specific example of the error (log file, screen capture, printout, etc.) so that you can see exactly what error they are getting.

As a good sys admin, you are wise to resist efforts to solve problems by throwing disk space at it, jacking up kernel parameters, etc. It may seem a little harsh, but you will serve them better by resisting efforts to solve problems until you know what the specific problem is.

Hang in there!

JP

[John Kittel]

Also, application could be trying to create new file but file by the same name already exists, with different /incompatible owner, group, protections. That one happened to me last week with some purchased s/w.

To add to the point JP just made, I would say it is wise to resist efforts to solve problems merely by implementing the solution proposed by the customer without knowing for yourself what the cause of the problem is.

[John Kittel]

Oh sorry. I didn't add to JP's idea. I just repeated it. ( must read more carefully...)

[Dani Seely]

If the application is continually adding new files to the filesystems, and never deleting them you can create a cron job to compress them for debugging later or remove them.
You can use 'compress' or 'gzip'. If you have problems with disk space on the drive where your large files are stored, you should find a filesystem with available free space and create an archive directory to move the files to and then compress them there.

You can set up a crontab entry to save off and compress the files based on their age and then move the file to the archive directory. The two commands you would set up in the crontab woud be something like:
find -mtime +1 -exec compress -f {} \;
mv *.Z

If you'd rather delete them, just use the find command and perform a rm of the file(s) found.

[KapilRaj]

How often do they shutdown the server ?. If it is not a daily shutdown I would ask you to implement a cron job to perform a cyclic housekeeping of old log files in /tmp something like "files not used for last 2 days, wipe-off" !.

Regds,

Kaps