Arrrgh! hosting company accusing us of "not closing sesssions"

Can anyone explain to me what my hosting company are going on about?

Basically we are being accused of running scripts that are not closing their sessions properly ... We are only using vbulletin, a few hacks, a gallery and a portal. It is on a shared server, but normally runs trouble free.

It started at the weekend with vb giving us the following SQL error:

MySQL Error : Error writing file '/tmp/MYORhmER' (Errcode: 28) Error Number : 3

On certain pages. We also cannot get into phpmyadmin. That gives us this error:

Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/cpanel/base/3rdparty/phpMyAdmin/index.php on line 44

Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in /usr/local/cpanel/base/3rdparty/phpMyAdmin/index.php on line 44


We submitted a ticket, but within 20 minutes of doing so they suspended our site saying that our sessions "weren't closing", we have persistent connections turned off. The site has been running trouble free for over a year before this.

We spent a whole day negotiating with them and they finally allowed us back on after emptying the 'tmp' directory and saying it was us that was filling it up.

Thing is, it's happened again today. We've turned our forum off while we investigate, but we know that as soon as we raise the issue they will blame us again.

Can anyone tell us what we need to say to convince them it isn't us?

Or is it us and if so what can we do?

----

Ha, and now we've been suspended again.

*moans at the 'automerge' feature, that was supposed to be 2 posts*

[moonclamp]

Originally Posted by Reeve of shinra

This may not be related to your issue but edit your postbit template and delete the changes you made for vbjournal. There is/was (not sure) an issue where your query count would sky rocket if it was a large thread with a lot of posts.

You mean the go to journal dropdown? Yeah I could do that but it somehow seems unlikely. Cheers.

Originally Posted by SoftDux

If the DB is so large, and you do have cPanel, then use the backup to remote server via FTP feature instead. I have succesfully transferred 1GB backup files like that before from one host to another, even from the UK to the USA.

The cpanel backup and restore times out too. But the gzipped database is a lot smaller.

I'm not sure what you mean by "backup to remote server via ftp". I can't see this as a cpanel option.

[Reeve of shinra]

You mean the go to journal dropdown? Yeah I could do that but it somehow seems unlikely. Cheers.

Yep thats it - my query count jumped up by 100 per page because of this.

[danielcompton]

is your host 1and1? if so I had the same thing and they wont fix it they are rubbish. message me and I tell you how I got mine working again... isnt an easy fix.

if not 1and1 then it wont help you.

[moonclamp]

Originally Posted by danielcompton

is your host 1and1? if so I had the same thing and they wont fix it they are rubbish. message me and I tell you how I got mine working again... isnt an easy fix.

if not 1and1 then it wont help you.

No it's ukhost4u.

I looked into 1and1 and after reading their reviews and TOS I decided against them, thankfully.

Originally Posted by moonclamp

Anyway, transferring a 360 meg database to another host is a complete pain in the arse that I really don't want to deal with, I just haven't got the time right now.

Can't help you with the UK hosting problem, but I will offer a tip here. If you have your new host setup, toss your DB in a web-accessible directory on the host you're moving from. Then:

wget your.url/youdbackup.sql

And voila, your old DB is on your new server, without you having to deal with home based connect speed limitations. I've moved 5+GB databases this way and it's a LOT easier.

[moonclamp]

wget?

Sorry, to clarify:

Shell into your new server, and type 'wget (the url)'.

http://www.gnu.org/software/wget/