Forums database errors server shut down due to hundreds of thousands of empty /tmp files being written

**Wayne Luke** · Wed 26 Dec '18, 8:35am

We don't tell MySQL to write and/or delete tmp files. It manages them on its own. These files will be created during normal operations. It seems that the MySQL user doesn't have permission to delete files from the /tmp directory and that needs to be rectified.

You cannot delete these files while MySQL is running. To resolve the database errors, you will need to restart the MYSQL server. Your hosting provider should have known to do this when deleting MySQL files.

**Maltair** · Wed 26 Dec '18, 6:04pm

Thanks! yes I read that, since then Hostgator has added the following, what do you think? Why are there 400K files in the temp?

"The current permissions on the /tmp directory should permit writing capabilites by MySQL."

"
Based on the error message reported, this issue does not seem to be permissions-related, but rather resource-related. As described earlier in the ticket, the issue is primarily related to the number of files being generated in /tmp. It is more likely that this error was caused by the container having hit a limit such as maximum number of files stored, maximum number of files opened, or a filesystem limit like maximum inodes in a single directory.
In reviewing the server state, I found about 400k files stored in /tmp from the past few days; I've gone ahead and cleared them at this time. It's worth mentioning that after clearing them, about 5 or 6 remained that were not empty - they contain HTML so it seems possible that this is related to a caching mechanism that stores page data after rendering it but fails to reliably delete the data afterwards.

Additionally, it may be helpful to change the container's PHP handler from CGI to SuPHP - this will cause PHP scripts to be run as the user they belong to rather than "nobody", primarily improving security but also making resource usage easier to track, especially when sites are hosted on separated cPanel users. We can do this for you if you like; it can also be done from root WHM.
"

**Wayne Luke** · Wed 26 Dec '18, 6:56pm

I have no idea why those files are there. They shouldn't be.

Any temp files created by vBulletin should be unlinked (deleted) once the system is done using them. If you are using mod_php, then the user that Apache is running under would need to be able to delete files out of the /tmp directory. If you're using mod_fastcgi or another method to call PHP, then the user that calls PHP needs to be able to delete files from the directory. The software relies on the proper permissions being applied to the proper users in order for operating system calls to work properly. If the hosting provider doesn't want software writing the /tmp directory, they need to configure the proper settings in their PHP config.

For the vbvurl files you can see why they aren't being deleted by editing /core/vb/vburl.php file and removing the @ in front of all the unlink() calls. This will cause the call to trigger an error if it can't delete the file.

The same goes for MYI and other files with MySQL. That user has to have permissions to manage the files at the operating system level.

**Maltair** · Thu 27 Dec '18, 9:34am

This is how my host responded:

"
Based on the error message reported, this issue does not seem to be permissions-related, but rather resource-related. As described earlier in the ticket, the issue is primarily related to the number of files being generated in /tmp. It is more likely that this error was caused by the container having hit a limit such as maximum number of files stored, maximum number of files opened, or a filesystem limit like maximum inodes in a single directory.
In reviewing the server state, I found about 400k files stored in /tmp from the past few days; I've gone ahead and cleared them at this time. It's worth mentioning that after clearing them, about 5 or 6 remained that were not empty - they contain HTML so it seems possible that this is related to a caching mechanism that stores page data after rendering it but fails to reliably delete the data afterwards.

Additionally, it may be helpful to change the container's PHP handler from CGI to SuPHP - this will cause PHP scripts to be run as the user they belong to rather than "nobody", primarily improving security but also making resource usage easier to track, especially when sites are hosted on separated cPanel users. We can do this for you if you like; it can also be done from root WHM.
"

1) Should I change PHP handler from CGI to SuPHP? I don't know that this will change anything, but may make the issue easier to track.

2) Why is this happening? 400K more /tmp files stored in past few days?

Part of why I am posting this publicly...is to determine if this has happened to anyone else?

**Wayne Luke** · Thu 27 Dec '18, 9:48am

1) If the PHP user cannot delete files out of the TMP directory then changing does nothing. This is a personal choice on your part.

2) Answered in Post #4.

Deleting files is definitely a permissions issue or server configuration issue.

**Maltair** · Fri 28 Dec '18, 10:10am

The host says that "The PHP: unlink is enabled and functioning. "

**Wayne Luke** · Fri 28 Dec '18, 10:25am

There is a disconnect somewhere. I can't create a large number of temp files on my test server, no matter what I try. They are deleted when the system is done with them.

Forums database errors server shut down due to hundreds of thousands of empty /tmp files being written

[Bug / Issue] Forums database errors server shut down due to hundreds of thousands of empty /tmp files being written

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Related Topics