It’s going to provide a ton of insight. If the BLF changes when you run that command manually then that means that the command is not in the crontab.
The ticketing system is meant more for reporting bugs when the issue is known. It’s not a support dialog. Since this issue is (right now) only you two we must work through it in some medium to figure out what’s going on. Thats what the forums are for.
Then when the issue is narrowed down we can move forward with a solution.
So after I ran that command (/var/lib/asterisk/bin/schedtc.php --debug), the user is now reporting that the light goes out timely at 8am when it should. Does that command actually do something or is it purely informational and the timing is coincidental?
This PBX periodically has this issue. If I manually run /var/lib/asterisk/bin/schedtc.php --debug while the light is (falsely) lit, the light goes out and it works for awhile (typically several weeks). The issue will then occur again, and calling in or running the command fixes the issue.
In the Advanced Settings, ‘Enable Maintenance Polling’ is set to Yes and the Maintenance Polling Interval is set to 60.
It doesn’t look like there is anything related to freepbx, asterisk, schedtc, etc, etc in the crontab. Would it potentially be in one of the other cron files? Can you give me an example of what I should be looking for, or what is needed to be added?
Somehow I missed your reply. Sorry and thank you for trying to move this forward.
/var/lib/asterisk/bin/schedtc.php --debug
Time Now:12:34|Wed|2|Aug|America/Los_Angeles
==Working with TimeCondition:Is During Business Hours==
INVERTED BLF: false (NOT_INUSE = NOT_INUSE & INUSE = INUSE)
OVERRIDE MODE: not set
=>06:45-18:00|mon-fri|*|*|America/Los_Angeles is now
TIME MATCHED: True (NOT_INUSE)
BLF MODE: True (NOT_INUSE)
Privilege: Command
Changing TC1 to NOT_INUSE
==Working with TimeCondition:Holiday==
INVERTED BLF: true (NOT_INUSE = INUSE & INUSE = NOT_INUSE)
OVERRIDE MODE: not set
=>11:09-11:10|*|*|*|America/Los_Angeles is not now
TIME MATCHED: False (NOT_INUSE)
BLF MODE: False (NOT_INUSE)
Privilege: Command
Changing TC3 to NOT_INUSE
I have not had a chance to see if the BLF updates when running this. I will try and check this tonight.
tail /var/log/cron
Aug 2 13:10:01 precendo CROND[15661]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:10:01 precendo CROND[15663]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:10:01 precendo CROND[15664]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Aug 2 13:11:01 precendo CROND[15774]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:11:01 precendo CROND[15775]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:11:01 precendo CROND[15776]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:12:01 precendo CROND[15852]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:12:01 precendo CROND[15853]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
Aug 2 13:12:01 precendo CROND[15854]: (CRON) ERROR chdir failed (/home/asterisk): No such file or directory
This led me to find this post:
I ran this command to add “/home/asterisk”
mkhomedir_helper asterisk
Now my cron log looks better. It includes the schedtc.php as expected.
tail /var/log/cron
Aug 2 13:16:01 precendo CROND[16192]: (asterisk) CMD ([ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php)
Aug 2 13:16:01 precendo CROND[16193]: (asterisk) CMD ([ -x /var/www/html/admin/modules/dashboard/scheduler.php ] && /var/www/html/admin/modules/dashboard/scheduler.php)
Aug 2 13:16:01 precendo /usr/bin/crontab[16205]: (asterisk) LIST (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16207]: (asterisk) LIST (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16208]: (asterisk) REPLACE (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16210]: (asterisk) LIST (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16212]: (asterisk) LIST (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16213]: (asterisk) REPLACE (asterisk)
Aug 2 13:16:02 precendo /usr/bin/crontab[16215]: (asterisk) LIST (asterisk)
I suspect that this will solve the problem as well as some others I may not have noticed.
I saw that the adduser command did have the -m which should have created the directory. But I looked at the history and saw that Andrew had just a few days ago corrected the command from -M to -m. I guess that is what happened.
It happened again this morning. It was fixed by an inbound call before I could run the command. Sorry for the unformatted post, having some issues with that.
I think my issue is different than np_pyro’s. My system does have an ‘/home/asterisk’ directory however it is empty. If I run the ‘crontab -l -u asterisk | grep schedtc’ no results are returned.
If I remove the grep and just eyeball it there are 15 lines and I don’t see anything similar in there.
If I review the /var/log/cron, I do see the command being ran, ‘Aug 11 08:43:01 cog-voip-01 CROND[18250]: (asterisk) CMD ([ -x /var/www/html/admin/modules/dashboard/scheduler.php ] && /var/www/html/admin/modules/dashboard/scheduler.php)’ including the version I have that is manually running the ‘/var/lib/asterisk/bin/schedtc.php --debug’ every 5 minutes.
If I grep those logs though for schedtc though, ‘grep schedtc /var/log/cron’ the results stop a few days ago.
I did not compile from source. It is a very old freepbx distro installed from iso that has been through a large number of updates. I am running:
*PBX Firmware: 10.13.66-20
*Asterisk: 11
*Framework: 13.0.192.9
The issue occurred again this morning and the user reporting it said it happens every day. I’m not sure that’s true, but possibly every day recently based on what I am seeing in the logs. If I run through ‘grep schedtc /var/log/cron*’ the last time I see it run is on Aug 9, which is the same as it was from my post on Aug 11. It looks like once the issue starts, it won’t resolve until I manually run the command.
Is crond failing? If the cron program is stopping, your cron jobs will not run.
check the existence and permissions on the file /var/www/html/admin/modules/dashboard/scheduler.php to make sure it is executable and exists. If it’s executable, it probably exists, so …
As a “bandaid” fix, I’d start watching crond to make sure it is running all the time.
Hate to drag up an old thread but am running 13.0.31.11 Time Conditions and seem to be seeing the exact same issue as described. The BLF/Hints seem to work for a random period of time and then just stop working. Honestly it’s probably been going on since the original post was made but we’ve just started using time conditions again within the past couple of months, so nobody had BLF’s defined.
Started running through some of the troubleshooting above and could swear that asterisk’s crontab did not have the schedtc line in it when I first checked. Then I noticed that there were again cron entries popping up in the log and when I looked sure enough the schedtc entry was in asterisk’s crontab. No way to tell if it was my imagination or not since asterisk’s crontab seems to be updated once a minute. Will definitely be checking for that first next time it stops working.