"processes that don't die"

This might have something to do with the way b2evolution processes some info on script shutdown. What version are you using?
Try to edit the shutdown() function in /inc/_core/_misc.funcs.php

// Try forking a background process and let the parent return as fast as possbile.
if( is_callable('pcntl_fork') && function_exists('posix_kill') && defined('STDIN') )
{

replace with

// Try forking a background process and let the parent return as fast as possbile.
if( false )
{

@sam2kb wrote earlier:

"processes that don't die"

This might have something to do with the way b2evolution processes some info on script shutdown. What version are you using?
Try to edit the shutdown() function in /inc/_core/_misc.funcs.php

// Try forking a background process and let the parent return as fast as possbile.
if( is_callable('pcntl_fork') && function_exists('posix_kill') && defined('STDIN') )
{

replace with

// Try forking a background process and let the parent return as fast as possbile.
if( false )
{

Thank you Sam, I'm going to ring Just Host again in a few hours time when their terms and conditions people start working again in America and I'll try your suggestion after that.

@tobw I fear terms and conditions won't help a lot. If for some reason something fails in the script and for some reason it kills their web server, it is normal that they block it. Also don't count on them for finding the problem: at that price you can't expect to get skilled technicians to investigate your site. @sam2kb suggestion sounds good.

@sam2kb Do you think it would generally be better to get rid of this forking code and process shutdown in the main script?

@fplanque
It should be perfectly fine to process shutdown in the main script.
Why do we want to return to parent script anyway (except for debugging)? The shutdown function is called the last and it doesn't lock any activities.

I think the original goal was to let the main process close the pipe with the webserver as fast as possible. The reasons were:

1) Some webservers would not gzip and send the content until the pipe was closed. I think this is a problem of the past.

2) It would let the server tell the client the transfer is done sooner, and thus the client would stop waiting for data faster. I am not sure this still applies.

Those points are/were particularly useful in case shutdown would do some heavy stuff like pruning the hitlog for example.

So are we talking about creating too many forked processes and some of them being zombies?
- we can make sure they don't run forever e.g. set an execution time limit
- and we can selectively fork some processes if a heavy stuff is expected instead of doing it for each page load

There's also an interesting function pcntl_wait()

Thank you both for your comments. I rang Just Host and spoke to someone who was far more patient and understanding when dealing with this novice - he was also able to explain the situation far more simply and clearly than his colleague had done and it turned out that the problem could be resolved through Just Host's CPanel, whereas I had been led to understand that this was not the case in my earlier telephone conversation.

Me being so frustrated and annoyed probably didn't help matters with that first conversation I had and I feel a little embarrassed to have put you to this bother when it turns out I needn't have done so if I had been given the right info, but thank you both very much for your concern and helpful attitude.

@tobw I would be very interested to know what you need to do in the control panel to fix the problem. Can you maybe post screenshots of what you're changing in there?

Thank you.