Chris Anderson Posted January 14, 2022 Posted January 14, 2022 (edited) I’ve installed the suite on a primary domain and two subdomains with the latest 4.6.9 version found in the Client area. Immediately after each install I setup a cronjob call using the cronjob.org web service. The primary domain shows proper timestamps for each successful task completion: Whereas as the subdomains show incorrect timestamps: I deleted the installs for all three sites and reinstalled with the same strange results. I thought at first that the server time might be off for the subdomains. I created a php script to show the server time for all three sites and they all show the same time. This seems to rule out a server problem. The incorrect times seem to be offset by 7 hours for the two subdomain installs. You can verify the times yourself by going to the following: mywebsite.com/time.php c-level.mywebsite.com/time.php m-level.mywebsite.com/time.php I have no idea if incorrect times are only being exhibited in the ACP "Task" section of the suite or the problem is more widespread. It’s interesting that the problem only shows up for the installs on sub domains and not on the primary domain as well. It makes me wonder if there might be other hidden problems related to hosting sites on subdomains. Edited January 15, 2022 by Chris Anderson
Chris Anderson Posted January 14, 2022 Author Posted January 14, 2022 Upon logging into the ACP immediately after each install completed, I simply copied the cronjob settings and clicked on "Save". I then navigated to the ACP "Tasks" screen and observed the tasks as they were run every minute by the cronjob service. No other settings were made that might impact the behavior of each install.
Randy Calvert Posted January 15, 2022 Posted January 15, 2022 Have you ensured that times show up in the correct time zone in non-IPB files? For example what happens if you create a file like time.php with the following contents: <!DOCTYPE html> <html> <body> <?php echo "The time is " . date("h:i:sa"); ?> </body> </html> I'm wondering if it's a server-based config issue. Check that file on all 3 hostnames and see if there is a difference.
Jim M Posted January 15, 2022 Posted January 15, 2022 This may seem like a silly question but are you accessing each install through the same means? (i.e. the same browser on your local machine). I ask as this could be a time zone difference being shown here. By chance, you're viewing this through a remote desktop machine and it has a completely different time zone, that would be expected.
Chris Anderson Posted January 15, 2022 Author Posted January 15, 2022 12 hours ago, Randy Calvert said: Have you ensured that times show up in the correct time zone in non-IPB files? For example what happens if you create a file like time.php with the following contents: <!DOCTYPE html> <html> <body> <?php echo "The time is " . date("h:i:sa"); ?> </body> </html> I'm wondering if it's a server-based config issue. Check that file on all 3 hostnames and see if there is a difference. This is exactly the syntax I had in the time.php script. Checked again and all three show the same time.
Chris Anderson Posted January 15, 2022 Author Posted January 15, 2022 (edited) 4 hours ago, Jim M said: This may seem like a silly question but are you accessing each install through the same means? (i.e. the same browser on your local machine). I ask as this could be a time zone difference being shown here. By chance, you're viewing this through a remote desktop machine and it has a completely different time zone, that would be expected. I just ran the time.php script via an Opera, Mozilla and Chrome browser instance on my desktop machine. Each browser pointing to a different site. I also tried all three scripts on my phone. The two systems are using different internet providers. All instances show the same time. Edited January 15, 2022 by Chris Anderson
Jim M Posted January 15, 2022 Posted January 15, 2022 6 minutes ago, Chris Anderson said: I just ran the time.php script via an Opera, Mozilla and Chrome browser instance on my desktop machine. Each browser pointing to a different site. I also tried all three scripts on my phone. The two systems are using different internet providers. All instances show the same time. The PHP script you have there would not interpret time zones from your browser but our software will. To confirm, you're using the same exact computer and browser when viewing our software?
Chris Anderson Posted January 15, 2022 Author Posted January 15, 2022 1 minute ago, Jim M said: The PHP script you have there would not interpret time zones from your browser but our software will. To confirm, you're using the same exact computer and browser when viewing our software? I'm using the same exact browser and machine I used to install your software suite on the primary domain and two sub domains. I am not using any kind of vpn or any other remote server software.
Jim M Posted January 15, 2022 Posted January 15, 2022 2 minutes ago, Chris Anderson said: I'm using the same exact browser and machine I used to install your software suite on the primary domain and two sub domains. I am not using any kind of vpn or any other remote server software. Thank you. Could you please update the credentials on file and we can take a look to see if we can determine a software reason for this.
Chris Anderson Posted January 15, 2022 Author Posted January 15, 2022 2 hours ago, Jim M said: please update the credentials on file Done After waiting 24 hours after the initial install on all three it appears that the time stamps all reflect accurate times. If I hadn't made screenshots yesterday, I would have thought I was maybe seeing things. All tasks seem to be running as scheduled and nothing has been logged in the System and Error Logs. If this happened on one install, I would attribute it to simply being a fluke, but it occurred on two separate sub domains and two separate installs. This leads me to speculate that there might be a flaw in the install script related to a site name including a sub domain that the installed software suite code doesn't have an issue with. So once the initial setup steps are completed and the software suite takes over handing the minute-by-minute running of tasks the time stamps start showing correctly. My concern is whether or not there might be other install script or software suite code that may exist that doesn't properly handle sub domains. I've looked for problems over the past few months but nothing obvious has presented itself or any issues logged.
Marc Posted January 17, 2022 Posted January 17, 2022 As there is nothing there for us to see any longer, there isnt really anything to investigate here unfortunately. What I am a little confused about with your initial topic there however. Are you saying they were showing incorrectly in the different areas using your own scripts too?
Chris Anderson Posted January 17, 2022 Author Posted January 17, 2022 I reinstalled the two sub domains and the adverse behavior is happening once again. You are free to investigate the two installs. I am not running any scripts other than those provided by the suite.
Jim M Posted January 17, 2022 Posted January 17, 2022 Unfortunately, I am not seeing this issue. Each tasks' last run and next run are all either 7pm or 8pm on both your root domain and sub-domains.
Chris Anderson Posted January 17, 2022 Author Posted January 17, 2022 (edited) The two sub-domain installs seemed to be working correctly after I observed it after the 24-hour mark. The subsequent sub domain installs initially showed a 7-hour time offset but showed the correct times when I observed them again 15 minutes after starting the cron job webservice. I will reset all three installs once again and provide screenshots if I observe the behavior once again. Edited January 17, 2022 by Chris Anderson
Jim M Posted January 17, 2022 Posted January 17, 2022 Unfortunately, to investigate and resolve this it would need to be more than a few moments here or a screenshot. We would need to reproduce it or see it effectively so our developers can investigate on your community.
Chris Anderson Posted January 17, 2022 Author Posted January 17, 2022 After reinstalling the main site and two subdomains the behavior switched. The main site is now showing a 7-hour time offset and the sub domains appear to be running correctly. This seems to eliminate the problem being related to sub domains. Here are the screenshots of the main site and sub domains during the first half hour after enabling tasks via webservice. screenshotsa.docx
Marc Posted January 18, 2022 Posted January 18, 2022 I have looped in our developers to advise on this. Someone will respond as soon as they get to it
Chris Anderson Posted January 18, 2022 Author Posted January 18, 2022 Even though 24 hours have passed since I installed to the main domain the tasks still show a 7-hour offset. The two sub domains show accurate time stamps. Here is a screenshot showing the 7-hour offset: Please let me know what additional troubleshooting your developers would like to do to help figure out the underlying problem.
Stuart Silvester Posted January 18, 2022 Posted January 18, 2022 Your administrator account is using UTC time (as is the default), it's not currently using your own timezone. We auto-detect this on the front-end. You should find that if you log in there, your admin user will set to the correct timezone. You can also see which timezone is in use on the AdminCP Member profile, on the left under Devices & IP Addresses.
Solution Chris Anderson Posted January 18, 2022 Author Solution Posted January 18, 2022 (edited) 33 minutes ago, Stuart Silvester said: Your administrator account is using UTC time (as is the default), it's not currently using your own timezone. We auto-detect this on the front-end. You should find that if you log in there, your admin user will set to the correct timezone. You can also see which timezone is in use on the AdminCP Member profile, on the left under Devices & IP Addresses. Logging into the front end did the trick of resetting the time zone for the admin account. Once logged back into the ACP the times showed correctly. Thanks for tracking this down for me. It's behavior I had never seen before after many, many installs so it seemed like something was amiss considering it wasn't consistent. Edited January 18, 2022 by Chris Anderson SeNioR- 1
Recommended Posts