Time Condition BLF Hint not updating until call received


I am creating a new system for a client. I made a time condition for their business hours and also assigned a BLF to monitor and manually change. It dials / subscribes to *271.

Setting the time condition to end a couple of minutes ahead of the current time I can call and test that the condition toggle does flip and I am sent to the proper IVR to announce that the business is closed. However, the BLF hint does not update at the indicated time. It only updates after a call has been made.

I checked the CLI using:
core show hints

Before call is received, but after time condition is flipped:
*271@timeconditions-: Custom:TC1 State:Idle Presence:not_set Watchers 1

After call is received:
*271@timeconditions-: Custom:TC1 State:InUse Presence:not_set Watchers 1

Was originally on current stable version of the Time Conditions module. Tried updating to EDGE version, and that didn’t seem to help. Tried downgrading to & .3 no help either.


Any ideas / help is greatly appreciated.

The BLF only gets updated when a call comes in or based on a interval. That default.interval is 10 minutes. You can change this in advanced settings module.


Thank you for the prompt reply.

I’m assuming that you are referencing the setting labeled “Maintenance Polling Interval” under the “Time Condition Module” heading. Based on the description this seems like the right thing.

Mine was set to 60 (seconds) already (the lowest).

I can say that the BLF status did not update over night which should have been more than enough time. I also tested this again by calling and it flipped the hint. The hint should have flipped again at 7:30 (20+ minutes ago) and has yet to do so.

Is there something that I can check to make sure that this background updating process is running?

I am not sure. Maybe someone else can assist.

What version of Time Conditions are you using? Version is available in the edge repo, which you can upgrade with:

fwconsole ma --edge upgrade timeconditions

As mentioned in original post I did try the edge version and a few rollback versions. Thanks for the idea though. Do you think I should go back even further?

np_pyro did you ever find a fix? We performed an upgrade with nearly identical circumstances and are experiencing the same issue. Polling interval is set to 60 and over the last 9 days it has not updated until a call came in.

No. :frowning:

I know that there has been an updated version of the Time Conditions module released since then, but I have not had a chance to test it since this system is now in production.

Let me know if you have any success. I would like to have this resolved.

/var/lib/asterisk/bin/schedtc.php --debug

I am running which is the latest as I understand it. I submitted a bug report but it was closed almost immediately by Andrew Nagy with a comment to follow the instructions in the forums. I see he posted on here. I ran that command and it outputs status of the Time Conditions and includes whether it matches and what the BLF state is. It’s quite useful actually. I don’t think it’s going to provide anymore insight that what we already have, but I’ll try to run it when the status hasn’t updated and see what happens.

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?

Yes. It changes the blf. Its the same command that is run automatically on the crontab.

You might have disabled the cron for this in advanced settings.

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.

Any suggestions?

Check the cron job in cron tab

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?

Your assistance is appreciated.

This is what you should see on a 13 system:

# crontab -l -uasterisk | grep schedtc
* * * * * [ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php
1 Like


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==
=>06:45-18:00|mon-fri|*|*|America/Los_Angeles is now
Privilege: Command
Changing TC1 to NOT_INUSE

==Working with TimeCondition:Holiday==
=>11:09-11:10|*|*|*|America/Los_Angeles is not now
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.

I do seem to have a crontab entry.

crontab -l -u asterisk | grep schedtc
* * * * * [ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php

I don’t see any entries in the cron logs however. Should I?

 grep schedtc /var/log/cron*  

I do believe that cron is running in general as I have entries in the logs for other items.

Thanks for the help!

Yes. You should see entries corresponding to the frequency you have set in advanced settings (mine is 5 min):

# grep schedtc /var/log/cron
Aug  2 13:35:01 lgaetzdev2 CROND[13899]: (asterisk) CMD ([ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php)
Aug  2 13:40:01 lgaetzdev2 CROND[14789]: (asterisk) CMD ([ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php)
Aug  2 13:45:01 lgaetzdev2 CROND[15697]: (asterisk) CMD ([ -x /var/lib/asterisk/bin/schedtc.php ] && /var/lib/asterisk/bin/schedtc.php)

I think I have found the problem / solution!

I found these errors in the cron log:

 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.