Closed TopicStart new topicStart Poll

> Cron Jobs, Setting up a phpCOIN lamp cron job
Posted: June 04, 2009 09:39 pm
Quote Post

The Janitor

Group: Admin
Posts: 3,638
Member No.: 3
Joined: August 25, 2006

A linux users guide to getting phpCOIN cron jobs working without actually tearing all your hair out !

Before we dive into the details of all the ways a phpCOIN cron job can be run, and explore the pros and cons of each, let's establish a few ground rules.

You must know where your files reside on your server – it's no use asking us – we don't know !!! We know where our files are on our servers smile.gif

I am not going to make any attempt to explain how to write a cron job from the command line, nor deal with the actual scheduling. You can read all about that using some simple Google searches or by consulting your control panel manual.

This guide assumes you have some sort of control panel and are competent enough to have clicked the right icons to land on the cron setup page and are wondering what to do next. (If you can't get this far, you need to go hire someone that can)

There are several ways that one can invoke a php file under cron and I shall examine them one by one and attempt to highlight any issues you may find.

For many years, the wget method of calling a php file was an easy means to an end.

It may work for you but you do need to be aware of some potential pitfalls. Wget is a utility for non-interactive download of files from the Web. It supports HTTP, HTTPS, and FTP protocols.
It would appear that, if run by a user that is not a member of the httpd group or the file ownership group, it tries to download the file to a folder within the home directory of the user that called it instead of caching the output into a tmp file and attempting to send the result by mail to the cron users mail account or discarding the output to /dev/null if specified.

Since it calls a php file, and assuming the php executes, the html output is what is downloaded and stored in the cron users home folder (probably “root” which you may not have access to) under the same filename as was called (if the php fails to execute, the resulting file will just contain the same code as the php file that was called). Subsequent calls will create additional files with the same name with an appended iteration number as described below.

Since wget was designed as a background, non-interactive downloader of html files, it would seem to be doing exactly as it was designed to do. The fact that we have been able to exploit it in the past within many server environments, to call and parse a php file and get the result we were looking for, was a bonus which is perhaps becoming obsolete as server security is progressively tightened up.. Our implementation of wget is a bit like using a screwdriver as a chisel, it often works but it was never really designed to be used that way.

Running the 'wget' cron job as root in a shared vhost environment,

/usr/bin/wget > /dev/null 2>&1

I observed the cron was ignoring the null output and writing a file into the root folder every run

The files were named:


Each file contained the html output of the parsed php file

Obviously, this could create a huge number of files in a home/root folder after a short time if you are running the helpdesk import every few minutes !!!

Adding the --delete-after switch to the call seems to be effective in taming this behavior eg

/usr/bin/wget --delete-after > /dev/null 2>&1

An alternative may be to pipe the output file into a /tmp folder and let the linux garbage collection process periodically clean them up.

curl is a tool to transfer data from or to a server, using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, TFTP, DICT, TELNET, LDAP or FILE). The command is designed to work without user interaction.

I should imagine the same criteria applies as above although you will have to consult your curl manual for the correct syntax to delete any downloaded file after use.

Lynx is a text-only browser that is occasionally deployed on server environments – if you have it, you may be able to use it directly to call your php files.

OK – this is the interesting bit and requires the most explanations !
Firstly, let's examine the Crontab Environment

cron invokes the command from the user's HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:

Now we must take into account that, for various reasons connected to cron hierarchy permissions in SELinux, most control panel developers seem to have opted to run all cron jobs under the 'root' user and avoid any complications in their lives. Unfortunately, this has complicated our lives instead.
Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry, so you do have an option of writing your own perl/python/shell script if you want to run under a different user.

For many years it was simple to run a php cron under lamp, all we had to do was issue a command something like:

/usr/bin/php -q /var/www/vhosts/ and everything worked !

More recently, running a phpCOIN cron job on a reasonably up-to -date lamp server as the root user often results in the error message similar to :

PHP Warning:  require_once(/root/coin_includes/core.php): failed to open stream: No such file or directory in /var/www/vhosts/ on line 24

We can see the cron job assumes the fileset is relative to the users (root) home directory instead of where the fileset actually resides.

There are several ways we can address this issue:

1) A user can hard code the absolute path to their include file from within the files called by cron
2) A user can set the include path in htaccess or from within their php files with the ini_set() function.
3) (My preferred solution) A user can issue a cron command as follows (without editing any of their php files):

cd /var/www/vhosts/ && /usr/bin/php -q /var/www/vhosts/ >/dev/null 2>&1

You can see here that we first CD (Change Directory) to the webroot folder of the vhost containing the phpCOIN fileset – in this case /httpdocs/files which in this example translates to an absolute path of /var/www/vhosts/ and, now we are in the correct starting folder, we then run the second part of the cron job (the && means “and”) by running our PHP call.

Well, that's all I am going to write on the subject of linux cron jobs – it's not really a phpCOIN configuration issue, and if you have got this far and still have no idea what I am talking about, perhaps you need to hire a competent systems administrator that does – and maybe ponder on how you are going to support your own hosting clients if they ever ask you to set up a cron job for them sad.gif

***** Unless otherwise stated, all replies refer to the following *****
--- The latest unmodified version of phpCOIN available from the phpCOIN download page on the date and time of this post.
--- All relevant HotFix files applied - One of the four included unmodified themes - The original language files .
--- Help will be given to install/configure/use phpCOIN, but not programming help to modify phpCOIN operations. If you are competent enough to make programming changes, you should be competent enough to read the source code and figure things out :)
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

Topic Options Closed TopicStart new topicStart Poll


Inscrita el Registro Mercantil de Mallorca Tomo 2140, Hoja No. PM-51034, Folio 135
This website owned and operated by: Technology Services RPVW S.L. CIF# B57345084
Avda Constitucion 48 Bajos Alaro 07340 Baleares SPAIN
Tel:+34 971518362    Fax: +34 971518368    eMail: