Jobs are permanently in "Starting" status

When Ultimate Cron starts a cron job, it executes this via Background Process by doing an http request using the service host information declared in the the background_process_service_hosts.

Assuming a single server setup:

vhost: example.com
ext ip: 12.34.56.78
int ip. 192.168.1.1

In a single server setup, you will usually experience what you are describing in these situations:

1.) Vhost configuration doesn't allow connections to example.com from localhost
2.) Ext-ip is not accessible from localhost 
3.) Host cannot resolve to ip from the host itself.
4.) Webserver is only listening on int-ip (which background process might not be able to determine automatically).

Troubleshooting:

1.) Check the "Allow/deny from" directive in apache conf
2.) telnet 12.34.56.78 80 from the host itself to see if it is possible to connect.
3.) host example.com from the host itself
4.) netstat -an | grep LIST | grep ":80"

if #1 is resolved and webserver is only listening on int-ip, then this could be a solution:

<?php
$conf['background_process_service_hosts'] = array(
  'default' => array(
    'base_url' => 'http://192.168.1.1:80'
    'http_host' => 'example.com'
  ),
);
?>

Ok. Did you include username/password in your $conf['background_process_service_hosts']? Could you post it? Of course change sensitve data to * or similar if necessary.

Background Process issues a POST request for executing a job, e.g.

POST /bgp:start/uc:search_cron/.....
(POST /bgp%3Astart/uc%253Asearch_cron/.....)

Do you have any entries in your apache log for these requests?

In the latest release of Background Process I use a ':' in the URL which might not work on some systems, as it is not RFC-compliant. This is fixed in the dev version of Background Process. Could you try updating Background Process to the dev version?

Hmmm .... You could try the dev version just in case, though i'm not sure that will solve the problem. Do you have any log entries in your watchdog from ultimate_cron or bg_process?

Are you using clean urls?

Recently I also got in trouble with this.
The solution was simple in my case : just click on "Determine default service host" on admin/config/system/background-process page (even if everything looks fine) and flush your caches.
In my case I've noticed that port changed.
I think the problem (in my case) was related to port.
Hope it helped.

I am having this issue also. I would really like to get Ultimate Cron to work. I know my cron tabs are working every minute but the cron doesn't seam to be running. After about 12 hrs I have a few jobs with the status N/A and they say starting.

If you're not already using the dev versions of Ultimate Cron and Background Process, please upgrade to these first.

One thing to note, is that if you're using the latest release of Background Process and also running the Drupal installation on multiple environments you might experience this when you're migrating the database. This particular issue is fixed in the dev version for the cases where $conf['background_process_service_hosts']['default'] is NOT configured manually in the settings.php file.

It could also be Ultimate Cron "simultaneous connections" setting that is too high for the webserver, and therefore the webserver may "drop" some requests without Ultimate Cron/Background Process being aware of it.

If you're using http basic authentication for your website, you will need to configure settings.php manually or click the "Determine default service host" button on each environment after database migration.

Another solution could be to use the Drush setup as explained here: http://drupal.org/node/1443264#comment-5752990

FYI: I'm currently working on making the entire Background Process launching of processes more robust, but that's in a very very unofficial/unready 2.x branch, and I'm not sure how of it can be backported to 1.x.

I have installed both dev versions and now i get a started "never" and a status "N/A". Its like cron never starts. I can click the run link and the job runs fine. This is my cron job
/usr/bin/wget --no-check-certificate --quiet -O - https://www.pickerspal.com/cron.php?cron_key=******************

The 'http_host' must not be a path. Use e.g:

<?php
$conf['background_process_service_hosts'] = array(
  'default' => array(
    'base_url' => 'http://user:mypwd@127.0.0.1:80',
    'http_host' => 'mydomain.dev'
  ),
);
?>

This should prevent the "malformed Host header" errors.

Are you using the same db for all sites (and db prefixes or not?) Depending on this configuration, you may need to run a wget for each site.

Hi adop

What is the resource that the POST request are trying to get and they cannot find? do I have a way to debug the request?

It should be something like '/it/bgp-start/..... What URL is specified in the access log for the 404 request?

Ah, the plot thickens. It seems that Background Process does not know about the prefix somehow.

Questions:
1.) How is the prefix (it, uk, etc.) implemented?
2.) Do you manually set $base_url in the settings file? If so, how?

Ok. I'm trying to recreate your setup, in order to debug a little. How did you configure your system to choose a different database depending on the site? Do you have separate settings.php for each site? If so, how are they invoked?

I've now tried using a multisite setup similar to what you described. It works out of the box for me. However, I believe I have found a bug in the "determine service host" logic, which can make it fail on systems where "mydomain.dev" resolves to an ip address that is not accessible from localhost.

After discovering this, there's one little thing in your background process configuration which I didn't notice earlier.

You should add the "it", "uk", etc. to the base_url, for example:

$conf['background_process_service_hosts'] = array(
  'default' => array(
    'base_url' => 'http://user:mypwd@127.0.0.1:80/it',
    'http_host' => 'mydomain.dev'
  ),
);

Could you try updating your settings.php's like stated above and see if that works? You have to add it to each site's settings.php.

I'll devise a fix for the "determine service host" logic in the meantime. When the fix is ready, you should be able to use that feature instead of manually configuring background process through settings.php, should you prefer this.

Hi adop

Ok. I've committed a fix to the "determine default service host" logic to 7.x-1.x-dev.

Note, that when manually configuring $conf['background_process_service_hosts']['default'] in the settings file, the "determine default service host" has no effect. Also, in a setup like yours, I would recommend manually configuring background process via the settings file, especially if you have dev/prod environments and do database migration once in a while. In those kind of setups, Background Process might send the request to the wrong environment, if "determine default service host" is used.

I'm gonna set this to fixed for now.

If you ever need the "Determine default service" host functionality, please re-open this ticket or create a new one, and then we'll do some investigation/debugging on this issue.