Fresh Install Cron Issue Error

Warning: getdate(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /home/www/mysite.com/periodic/cron.php on line 127

Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /home/www/mysite.com/inc/classes/BxDolTextData.php on line 113

Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /home/www/mysite.com/inc/classes/BxDolTextData.php on line 113

Above is the email cron error I am getting for a fresh install.

Edit the date zone in the php.ini file and restart Apache

Now I removed all emails and the cron to stop everything and I lost the command I am supposed to use given to me by the system.. I remember it started with "cd"

This what php.ini shows

; Defines the default timezone used by the date functions
;date.timezone =
;date.default_latitude = 31.7667
;date.default_longitude = 35.2333
;date.sunrise_zenith = 90.583333
;date.sunset_zenith = 90.583333

I filled in the blank timezone with an approved entry from php.net.  So far if I am not speaking too soon I have not received an email yet giving any errors.  However the test email in the host tools audit in the admin panel still fails.

Spoke too soon.. Nothing has changed.  Waiting for Apache to restart. Forgot that part.

; Defines the default timezone used by the date functions
;date.timezone = America/Kentucky/Louisville
;date.default_latitude = 31.7667
;date.default_longitude = 35.2333
;date.sunrise_zenith = 90.583333
;date.sunset_zenith = 90.583333

Ok Apache restarted and still get the following error.

Warning: getdate(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /home/www/sportsnerdz.com/periodic/cron.php on line 127

make sure you dont have 2 copies of your php.ini file. There should be one somewhere for the server, and sometimes there is one inside of the public_html folder or the main folder for your web site. I have seen this happen before and the one in the public_html folder did not have the proper date and time settings, but that php.ini file was not needed.

Thanks I am familiar with what you are talking about.  There are no local .ini files in the folder structure. Just the main one you referenced.. Maybe I need to wait longer for php.ini to take effect.

Warning: getdate(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /home/www/sportsnerdz.com/periodic/cron.php on line 127

 Looks like it's commented out. So it has no effect. Remove the ; from the front of the line i marked above.

And fixing the date will not fix your email test problem. Crons emails are not sent by dolphin, so the two are not related.

If you installed the smtp mailer mod, make sure it's properly configured. For 99% of all dolphin sites, the smtp mailer module is not even needed and should not be unless you have a specific need for it.

Thanks deano.. I caught onto the date being commented out bout 20 mins ago.  I then fixed that issue and rebooted the server.  So far still the same error message. Im working on it.

Ok, so answer this question. Where is that php.ini file located?

If it's a dedicated server is this the master php.ini file you are editing?

If not, you may not be aware that per directory php.ini files may have no effect on cron. This is because cron is run by the server and uses the CLI(command line version) version of php which is not the same as the apache web server uses.

It is a VPS. The location is sys/php5.4/php.ini

There are no other php.ini files in the sub directories or the root of the installation.

You may have to contact the host of the vps.

That php.ini location is very strange. Normally master php.ini files are somewhere under the /etc directory on the server. So you have a strange non default install of linux that i am totally unfamiliar with.

The edits of that file reflect this:

; Defines the default timezone used by the date functions
date.timezone = America/Kentucky/Louisville
;date.default_latitude = 31.7667
;date.default_longitude = 35.2333
;date.sunrise_zenith = 90.583333
;date.sunset_zenith = 90.583333

date.timezone = "UTC"

Also rebooted the server but no effect.  I am doing something wrong.

Oh. and the date timezone is a string not a number so it needs to be in quotes.

date.timezone = "America/Kentucky/Louisville"

 I am contacting them now.  I knew it would seem strange to you. I do run a special linux set up but I have never had problems getting php.ini configurations to update.  Thanks for your help Deano and others who have posted. I will updated this thread when I come up with the fix.

I will post this again in-case you missed it. The Missing quotes would most likely create a error and not work. This is what i posted before.


Oh. and the date timezone is a string not a number so it needs to be in quotes.

date.timezone = "America/Kentucky/Louisville"

Oh I did miss that.  Let me try this.

OK you p[osted this:

; Defines the default timezone used by the date functions
date.timezone = America/Kentucky/Louisville
;date.default_latitude = 31.7667
;date.default_longitude = 35.2333
;date.sunrise_zenith = 90.583333
;date.sunset_zenith = 90.583333

date.timezone = "UTC"

And from looking at that, you have 2 entries for the date.timezone - is it possible they are conflicting with each other?

I separated the 2nd entry because it is lower in the document and says UTC by default. This might be the who issue because adding the quotes did not change anything. I think you might have solved this.. Let me try correcting this.

Ok I replaced "UTC" with "America/Kentucky/Louisville" and I commented out the first entry containing date.timezone =

So far there is no change. I rebooted the server after making the php.ini changes. I suppose I'll wait until I hear back from the hosting provider.

The host has replied but I am not sure how to follow their instructions.

Hello,

Thank you for contacting our Technical Support Department.

Please note that the issue is with the settings in: home/www/mysite.com/periodic/cron.php not with the settings of the server.

You should edit the file and force it to use: date.timezone setting or the date_default_timezone_set() function instead of: getdate()

Best Regards,
Tom Alexander

That's a load of crap. Rewriting dolphin is not the answer. Given that some of those errors not not just from the cron file. I really despise hosts that will blame the script. It just means they don't know anything about dolphin.


After re-reading the errors i have a bad feeling.

What version of php is installed on this VPS?

I have multiple versions of php to choose from. I am currently using 5.4.15. I have the choice to use that version, php4, php 5.2, 5.4, and 5.5 (RC1)

The bad thing is that I do not have this problem on my other installation.. That is what confuses me.

The only thing different I can think of for my other installation is my cron job for that has a different command.

 Working Install Cron Command: TERM="xterm"; /usr/bin/lynx -dump http://mysite.com/periodic/cron.php >/dev/null;

Non Working Install Cron Command: cd /home/www/mysite.com/periodic; /usr/bin/php -q cron.php

Deano changing the cron command is making it work.. No more errors and emails are now processing on the site.. Im savvy but not enough to know why..

Just a quick thought from what I just noticed. In the cron command that is listed by default to be used, there is this:

/usr/bin/php -q cron.php

and in your working cron you have:

/usr/bin/lynx

so wondering if:

cd /home/www/mysite.com/periodic; /usr/bin/lynx -q cron.php

would have worked.

Just curious as I noticed this when you posted your working and non working crons

It doesnt matter now that you have it working, but it may come in handy if someone else runs into the same problem.

I have to say, running the cron through Lynx is an interesting solution...

off-topic (kinda) and because I am a lil slow, but; what is Lynx?

cd /

find -name php.ini

will find you all php.ini files on the server via ssh

also what is dolphin admin telling you is loaded for php.ini in the host tools ?

Just some things that might have helped you along sooner i suppose. 

 I've not tested this but it seems plausible for it to work. Good point.

Which aspect of php are you referring to that the host tools would be telling me in the admin panel?

 I am just happy it works.  I forgot about my old installation not running the given cron command during install either.

After all this discussion I discovered that the cron is not working.. When I execute it manually through the url no emails in queue are sent.. This is bothering me..

For others coming in on this; note that the first part of php.ini often shows examples.  Then later down in the php.ini file are the actual entries.  In this case, the user had edited the example section of php.ini.  If later in the php.ini file the datezone is set to something else, or set to nothing, it will override the the change made in the example part of the php.ini file.  One is not suppose to change the example part but the actual settings below the example part.

Now for those using php-fpm and are using pools, please note that you can have settings for php in the pool that will override the settings in php.ini.  This is very powerful as you can have pools for different conditions and each pool can have php settings independent of the main php.ini file.  this is similar to having different php.ini files in directories.

open the cron.php file in /periodic and add an echo line to the file so you actually get an output.

echo "cron.php has executed"; or some such thing.  Now you can test your cron job and get some visual feedback that it is executing; that the file cron.php did in fact execute.  If you see that it is executing, then you can know that it is not the cron job and look elsewhere.  Once you know that cron.php is actually executing, you can remove the echo.

Placed the echo message in the file. It shows and the file executes but no emails are being sent.

Is your cron setup to run once a minute?

Something else you might want to try until you get this working is to take >/dev/null off the end of the command.. that silences the output of the cron.

I removed the dev null.. Now I get an email every minute but it is blank with not text or errors. Also yes it is set up to run every minute.  I installed the SMTP mailer, not what I wanted to do but emails are sending that way.

EDIT-- Taking the dev null off the end is making the cron work.. Emails seem like they are firing now but I get a blank email every minute.  Unless the SMTP mailer is making this happen.  I just got the periodic report for the first time.

 That's really odd, the cron is only supposed to email you if there is something output when it runs. Oh wait is that test line you added still in cron.php? That might be the cause of the blank email.

I think the SMTP mailer is what actually fixed your problem though.

Yeah it was the SMTP that fixed the issue of mail.. I disabled it and back to square 1.  I did not have the test line in the email any longer.  The cron.php is stock from the 7.1.3 installation.  I am near my end with this cron thing. Every new install I have this is an issue.. Now I have no idea why it works on my installation I have and not the other.  I assume SMTP will do the same job as cron?

 No they're two different things...

The SMTP mailer is a module that forces the site to send mail through SMTP instead of sending it directly from php. Most people never need the SMTP module unless the server is blocking mail directly from PHP for some reason. I would say probably 99% of hosts allow mail directly from PHP.

The cron is how a server automates tasks.  Dolphin uses it to run cron.php and do things like send mass mail and process vids etc.

So mail on your other sites work without the SMTP module?

Yes mail on my other site works fine. They are 2 seperate VPS accounts with the same provider using the same version of php.