Resolved Setting up cron job

Assuming that the path to the PHP executable is correct, it looks good. You have set in your template to allow cron usage?

I believe that the destination file should be the one in my template settings?

Correct, that is the destination you set on the Source tab.

Thank you for the answer, rolandd. Now I wonder, what exactly should there be in the folder for the php executable? A listing for the one I used is:
root@vps [/usr/local/lib/php]# ls
./ .channels/ .depdblock .filemap pearcmd.php Structures/ XML/
../ Console/ doc/ .lock PEAR.php System.php
Archive/ data/ docs/ OS/ peclcmd.php test/
build/ .depdb extensions/ PEAR/ .registry/ tests/
root@vps [/usr/local/lib/php]#
Is this the correct path/folder? How would I recognize the "php executable"?

Another question, same subject: In the instructions for building the cron command there is a line saying "The password belonging to the supplied username.". Where do I supply a username, and what username should it be? The username for Joomla, or for the server - or which? The secret key, I believe is the one specified on the tab "Details" just beneath the setting "Enable front-end/cron", isn't it?

Hello,

Is this the correct path/folder? How would I recognize the "php executable"?

I don't administer your system, so I don't know which is the correct path, your hosting provider should know.

You can test this by doing

/usr/local/lib/php -v

as it gets you the PHP version. If that is a new version it should be good enough to be used.

The secret key, I believe is the one specified on the tab "Details" just beneath the setting "Enable front-end/cron", isn't it?

Correct, that was a typo and I have fixed it now. It is the secret key field in your template.

Thank you, rolandd.

The path was incorrect, but I found a path to php where I got an answer:

root@vps [/]# /usr/bin/php -v

PHP 5.4.45 (cgi-fcgi) (built: Sep 27 2015 12:06:37)

Copyright (c) 1997-2014 The PHP Group

Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

    with XCache v3.2.0, Copyright (c) 2005-2014, by mOo

    with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd., and

    with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies

    with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo

But though the cron job is run, it still does not produce any output.

Oct 31 06:00:01 vps CROND[24019]: (xxxuserxxx) CMD (/usr/bin/php /home/xxxuserxxx/public_html/administrator/components/com_csvi/helper/cron.php --key="######" --template_id="5")

(from the cron log).

The cron job is run as the user (masked) so there shouldn't be any permissions problems for writing the output, I believe. When I run the export from Joomla backend, it does produce the output file, according to the settings. Thus the template seems OK, but somewhere around the call to the helper/cron.php things don't go as they should. The path to cron.php is correct, tested with ls /home/....../cron.php.

Hello,

Ok, that looks like a good PHP.

Let's see if you get any output at all. If you run the job as

/usr/bin/php /home/xxxuserxxx/public_html/administrator/components/com_csvi/helper/cron.php --help

do you get the help screen?

Hi, where would I see the output, the help screen? Should I run this in the console?

Hello,

If you run the command from the console, you should see it in the console. When running it as a cron job, the server usually mails the cron output to the given email address set in the cron page.

Hello,

After changing the email setting I got this in my inbox from the cron daemon:

X-Powered-By: PHP/5.4.45

Set-Cookie: 56e0941d45fa9d1c05b076d061f96ef5=2df5108c941a8c2b5f8c9db2a618b47c; path=/; secure; HttpOnly

Content-type: text/html; charset=utf-8

Not much for a help file, is it?
Actually, the result is the same as when I ran the command in the console. It does not say anything to me. Could the problem be something abount privileges to run php scripts? I could try to put the command in the root's cron file, or maybe, if there is, Apache's?

:laugh:
Wow!

Found the error! The command needs the flag -f between the path to php and the path to /[...]/helpers/cron.php to make it run. Yes, when I got it running, I saw it in the help file that came in the mail... -f for parse and execute.

Nope. The command to get the help file runs just fine, but the export command throws this error message:
Error in argument 3, char 2: no argument for option -
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]... etc.
Quite close now, though.

So it seems like the cron daemon is interpreting the parameters meant for csvi as options to itself, the double dash before key (--key) is split into a dash for option and the second as argument, which is "illegal". So passing the variables to the php script this way does not seem to work on the present configuration: CENTOS 6.7 x86_64, Apache/2.4.16 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4, and:
Default PHP Version (.php files) 5
PHP 5 Handler suphp
Apache suEXEC on
Apache Ruid2 off

Installed Packages
cronie.x86_64 1.4.4-15.el6

Thanks for the feedback, it is appreciated. I have added a note to the cron job article.

Hi rolandd,

I'm sorry, but I don't really understand "...a not to the cron job article", is there something new that I could read?

I noticed another thing, the parameter --help is correctly interpreted and sent to cron.php - or would this be built-in in cron? From what I have read in other forums about passing parameters to php scripts through cron, they should be written as just the value, no dashes and no variable name, thus not like --key="####" but only #### and then they need to be taken care of in the php script from the argv array, in the order they were given in the command ($key = argv[1]; and so on, argv[0] being the path to the cron.php script itself).

I have another problem too, it is about which database table the values for "basepricewithtax" (Virtuemart product export) are taken, or wheter they are calculated. For this I probably need to open another thread.

Hello,

I'm sorry, but I don't really understand "...a not to the cron job article", is there something new that I could read?

It is a typing mistake, it should be note

From what I have read in other forums about passing parameters to php scripts through cron, they should be written as just the value, no dashes and no variable name, thus not like --key="####" but only ####

That is not how the Joomla CLI works.

As for your other problem, you need to open a new thread please unless your question is whether they are taken or calculated. I can tell you that they are calculated by VirtueMart. The only price stored is the base price, every other price is calculated from that.

Thank you for the information that prices with tax are calculated, it led me in the right direction on where to look for the culprit. It turned out, that products with shopper groups were excluded from the calculation. A backup of the table first, and then TRUNCATE TABLE `prefix_virtuemart_product_shoppergroups` solved this problem.

As for the problem with passing the key and template_id this happens in the cron command, before it gets to the cron.php file:

Error in argument 3, char 2: no argument for option -

Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]

       php <file> [args...]

  -a               Run interactively

  -b <addressort>|<port> Bind Path for external FASTCGI Server mode

  -C               Do not chdir to the script's directory

  -c <path>|<file> Look for php.ini file in this directory ...

The second char is the second dash, and then follows the help file with the usage instructions. So I don't think the call reches the script at all.
If I remove the dashes, and put either key=### or just the key, and the same for the template name, there is a "silent fail", ie. the php script gets called, but there is no output. Nether is there any mail.
So I an sorry to say, but double dashes don't work in the command, at least in my configuration.

So I an sorry to say, but double dashes don't work in the command, at least in my configuration.

That is then something related to your configuration. Would it work if you use a single dash?

If you have a look at this explanation, you will see we use the single and double dash. This is from a tutorial on how to build a Joomla CLI application.

The $this->input->get('h') code is looking for a -h flag on the command line. This is a boolean condition - it’s either there or it’s not. This is usually referred to as the short form of a command line argument.

The $this->input->get('help') code is looking for a --help option. This is the long form of a command line argument and it can actually take a value. For example, if you used the following on command line:

$ php -f tagaliser -- --help=now
then $this->input->get('help') would return the value “now”.

(source)

The only thing I notice in the article that he has -- after the filename. Notice he doesn't use the -f switch either

there is a "silent fail", ie. the php script gets called, but there is no output.

Nothing happens as no arguments seem to be passed.

To see if arguments get passed from the command line the defaukt way, I wrote a little test.php file:

$txt = "arguments given: " . $argc . "\n";

$txt .= print_r($argv,true);

$mf = fopen("testfile.txt", "w");

fwrite($mf, $txt);

fclose($mf);

When run like this:

/usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php key### 5

it produced a text file with this content:

arguments given: 3

Array

(

    [0] => /home/domain/public_html/administrator/components/com_csvi/helper/test.php

    [1] => key###

    [2] => 5

)

So this way works. The same file run with double dashes:

root@vps [~]# /usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php --key=key### --template_id=5

produced an error message, and the usage instructions:

Error in argument 3, char 2: no argument for option -

Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]

       php <file> [args...]

  -a               Run interactively

  -b <addressort>|<port> Bind Path for external FASTCGI Server mode

  -C               Do not chdir to the script's directory

  -c <path>|<file> Look for php.ini file in this directory

  -n               No php.ini file will be used

and exactly the same with single dashes.

Now I'll test another idea: a small php file which assigns the values from the cron command the way Joomla CLI wants them before calling the cron.php file... Just a :silly: idea.

I don't know if you are a user of Akeeba Backup, this very popular backup extension for Joomla also has CLI scripts for running backups. Their CLI scripts also require the double dash as explained in their documentation.

In your case this wouldn't work either I think, which does make your setup a little different from the rest.

Your idea is something you can try for sure.

Akeeba works perfectly. I believe that the problem is in the cron command line, which would not accept parameters with any dashes, only when they begin with any other legal character. Makes me wonder if it could be possible to escape the dashes in som way.

Makes me wonder if it could be possible to escape the dashes in som way.

I have no idea. I doubt it though. What I am more curious about is why it is an issue on your system. You are not the first one to use the cron script

Looking at the Joomla code, the arguments passed are being parsed based on the ==.

Looking at the Joomla code, the arguments passed are being parsed based on the ==.

There it is, the treatment of the $_SERVER['argv'] values. As there is no way to make the cron command line to accept the double dashes, there is a need of this script being able to handle parameters without them. I can pass parameters like

root@vps [~]# /usr/bin/php -f /home/domain/public_html/administrator/components/com_csvi/helper/test.php key=key### template_id=5

and they get into the $_SERVER['argv'] array, look like:
Array
(
[0] => /home/domain/public_html/administrator/components/com_csvi/helper/test.php
[1] => key=key###
[2] => template_id=5
), so I will have to see if there needs to be another conditional clause to handle such input, ie split the array values on the "=" sign and assign $out[$key] = $value; from that. It ought to be there already, but as it does not work, I will try to add this, although it is a core file I'll be hacking.