I'm trying to setup the cron job to run...I used the format from the installation guide;
/10 * * * * /path/to/php -q /path/to/comoblog_batch.php
The problem I'm encountering is with this part of the command:
First what does the -q do?
Also is /path/to/php supposed to point to my php folder? My host is running PHP, but I have no PHP folder....so I'm not sure what it is pointing too.
I actually installed the Batch Module. It seems to work...it posted the message I had sent. What is the prefered method though...the cron or the batch module? If it doesn't matter then I'll just stick with the batch module, but if running Cron is prefered I'd rather figure out how to get the command used correctly.
Sorry for the slow reply, I'm overseas at the moment.
The preferred method is the cron job if you can get it working, but mod_batch is fine to use as well. The only issue with mod_batch is if your POP3 server is slow then the first user to access your blog since you have posted can get hit with abit of a "delay" while the page fully loads. Since it's an inline image though it's hardly noticable.
"/path/to/php" should point to the PHP binary on your server - i.e. something like "/usr/bin/php" or "/bin/php". Ask your hosting provider, they will be able to tell you where the PHP binary is located.
The "-q" tells the php binary to execute that .php file from the command line. The PHP binary is used to being called from the webserver so the "-q" allows that PHP file to be executed from an interactive terminal session instead. If you have SSH/Telnet access to your host then you can run the command yourself manually to ensure everything works before cronning it.
I have a problem with the cron job. Not really the cron job itself but the comoblog_batch.php script.
I run www.carpeboobies.com (silly name, please disregard.) I was using the module rather than the cron job and all was working fine until at least 5/30/07 at 17:31 server time, as can be seen from the contents.
I did not submit another email to the configured mailbox until 6/11/07 and nothing is getting picked up from that mailbox. Going through my hosting provider's support hasn't given me much, they're not aware of any system changes. I have personally made zero content, PHP or MySQL database changes at all since prior to 5/30/07.
I have go so far as to install another instance of Comoblog with a new database and it will not pick up the emails either. If I run the script in a browser, I just get comoblog version 1.1 and a timestamp. The debug option doesn't seem to log or give me any other output.
I've just set this up as a cronjob and I'm now getting this:
PHP Warning: main([path of site]/include/param.inc.php) [<a href='function.main'>function.main</a>]: failed to open stream: Permission denied in [path of site]/include/config.inc.php on line 3 <br />
Additional fatal errors all revolving around that param.inc.php and config.inc.php files. I'm no expert at solving Linux PHP and permission problems. What might anyone suggest?
I assume you don't have console (i.e. SSH) access to this server ? Via a FTP or web admin program like Cpanel, can you see what the permissions are on the config.inc.php and param.inc.php files ?
According to my host provider, no. They tell me that while they do have some servers on which PHP runs in CGI mode, the server my site is hosted on has been running PHP as an Apache module since initial setup and has never been modified.
So I'm still stumped about why it's receiving permission errors.
What happens when you try and run that PHP script from your shell ?
i.e. php -q path/to/comoblog_batch.php
I get this:
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20020429//usr/local/lib/php/ixed.4.4.lin' - /usr/lib/php/extensions/no-debug-non-zts-20020429//usr/local/lib/php/ixed.4.4.lin: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: main([path to comoblog]include/param.inc.php): failed to open stream: Permission denied in [path to comoblog]/include/config.inc.php on line 3
Warning: main([path to comoblog]/include/param.inc.php): failed to open stream: Permission denied in [path to comoblog]/include/config.inc.php on line 3
PHP Fatal error: main(): Failed opening required '[path to comoblog]/include/param.inc.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in [path to comoblog]/include/config.inc.php on line 3
Fatal error: main(): Failed opening required '[path to comoblog]/include/param.inc.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in [path to comoblog]/include/config.inc.php on line 3
Well, that first line looks pretty awful and indicates something broken with your hosts PHP configuration - but I doubt it's causing your problems.
Infact, if your param file is owned by nobody then what you are seeing there is probably normal.
What is the APOP option in your Comoblog configuration set to ? If it's yes, have you tried changing it to no ?
Right. First, I had my host provider look at the dynamic library error and that's resolved.
Obviously when I run the script from a shell as my user account, I will run into permission errors with param.inc.php since it's owned by nobody with 600 permission. When I access the batch script from a browser or lynx dump, or if the hosting provider runs it with root privleges, all he or I see is this:
CoMoblog 1.1 batch - 2007-6-18 3:24:32
Now, the APOP setting - it set to no, and was always set to no as that's the default, and it was working.
What else could I look at, or have my host provider check?
I've now set up another clean install of CoMoBlog 1.1 at www.arizonaguy.com/comoblogtest - but still no go. No error when I run the script from a browser, just the ECHO of Comoblog 1.1 and the current date/time.
This worked fine before so obviously SOMETHING on the server changed. I just have no clue what that would be, and hosting provider has no idea either. I'm frankly very annoyed since something broke that was working through no intervention of my own.
All your help so far has been greatly appreciated, so thank you kindly.
Afraid this is going to be hard to debug remotely.
If you like, you can give me SSH access to your webhost and I can try and spot the problem myself, otherwise - we can email back and forth <comoblog [at] markwallis.id.au > and I can write you a version of the comoblog_batch.php script with additional debugging.
Up to you.
Actually, I do have shell access.
config.inc.php is 777.
param.inc.php is 600, owner and group are nobody as would be expected - right?
Your hosting provider hasn't happened to have changed the way they execute PHP code have they ? (i.e. from a module to CGI, or CGI with suexec ?)
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.