Modules won't upgrade?

Since yesterday, when I click on the check for online upgrades, it tells me that a bunch are upgradeable. I select upgrade all and click on process. I get the list of upgrades to do, and I click on process button. It then says the usual about “please wait while module actions are performed”, but nothing occurs subsequent to that. I suspect something yesterday went south on me (the announcements module is current marked as disabled due to an aborted upgrade then…)

UPDATE: what i’ve seen is that it will do a couple of modules, and hang after the “untarring…” message for one, and no further requests are processed, and the said module is b0rked.

please make sure to open a ticket,, or these will get forgotten. Too many things to keep track of otherwise.


ticket opened!

ok - download the latest FreePBX Framework module update and the symlink problem should be fixed.

I thought you said they were on the agi-debug, in any event, if php debug logging is enabled, they should show up in your system log also

sorry we seem to be miscommunicating. i started asterisk via the ‘-c’ flag and turned on agi debug and then saw a bunch of agi debug stuff, but nothing after dialparties.agi was invoked. the two error messages are apparently printed to error out or something, so they don’t show up on a remote console ;( as far as php debug logging, i guess that’s off by default (probably a good thing, due to performance hits), and i had no idea to turn it on, because i was focused on the idea that something was wrong with asterisk (like astdb). oh well. thanks for your hard work on this project! i’m really curious as to why this doesn’t fail normally - maybe the renaming/symlinking code is doing something different?

p.s. a heads-up for you: enumlookup.agi has the same issue (didn’t bite me, but noticed it while grepping thru agi files.)

Phillipe, did you read my post? I explicitly stated that the error messages do NOT come out on remote consoles, only the real one. I don’t recall being warned that half of the debugging code is useless unless you stop asterisk and then start it manually so you can see all the messages. Sorry, I don’t mean to be a jerk here, but I DID do my due diligence here :frowning:

UPDATE: the change you made did the trick.

p.s. just to be perfectly clear (since sometimes nuances get lost in email and forums and such), there was absolutely nothing printed from AGI debug. The cited error messages come out only on the primary console, not the remote session, which is why I never saw them.

I don’t want to rub anything in - but I mentioned on Saturday to do an agi debug…

anyhow, that is strange, I’ve got it running fine in another test environment I’m using. But … post a bug on the tracker, we should be able to specifically include the full path to that file since it appears some environments (like yours) are effected.

try putting in:

[code:1]require_once $config[‘ASTAGIDIR’]."/phpagi.php";
require_once $config[‘ASTAGIDIR’]."/phpagi-asmanager.php";

where the includes are today (and make sure the symbolic link is back in place). That should fix the issue (and if so, post in the ticket so we can get the fix in). Thanks for helping on the beta testing!

I ran the official beta procedure, and while the module updating is fixed, i’m back to dialparties.agi not working. i’m going to take a look when i get home…

agi debug at the cli and try the call, it will tell you a whole not more wrt to what is failing with dialparties.agi

Thanks! That did it. Here is what I get in console mode:

PHP Warning: require_once(phpagi.php): failed to open stream: No such file or directory in /var/www/html/admin/modules/core/agi-bin/dialparties.agi on line 25
PHP Fatal error: require_once(): Failed opening required ‘phpagi.php’ (include_path=’.:/usr/share/pear’) in /var/www/html/admin/modules/core/agi-bin/dialparties.agi on line 25

This is happening, as far as I can tell, because the dialparties.agi is now symlinked to the real one in /var/www/html/modules/core/agi-bin, and that causes the search path to fail. I temporarily deleted the symlink and restore the original dialparties.agi. Curious why this didn’t bite anyone else?

What REALLY p*sses me off about this is that I wasted a HUGE amount of time because the above messages are NOT printed to remote consoles, just the primary one. Sigh…

I need to re-prepare the tarball and remake the tag that is up as there has been a bunch of random moving around that may be related the the problem. It’s very possible you have your system in a broken state from all the messing around I’ve been doing the last few days.

Ah, okay :slight_smile: Should I redo my config or wait for a new tarball?

Well, to say I’m frustrated (and puzzled) is a gross understatement. I deleted EVERYTHING I could find related to asterisk and freepbx. Reinstalled asterisk 1.2.19 from scratch. Did the prep work for install_amp. Did the install_amp. Created the trunk to the VOIP provider for my DID. Created my two (IAX2 and SIP) extensions. Made an outbound call. Worked. Made an inbound call. Same damn thing with dialparties.agi! WTF??? I give up, I’m back to the partly-crippled config from earlier today, but at least my phones work :frowning:

UPDATE: I did a module update, and back to being b0rked. Clearly, something is not quite right. I rolled back to a stable config and will sit tight until an official update comes out.

well that didn’t do it. same identical failure mode. Here is the symptom:

Module Administration
Please wait while module actions are performed
Downloading timeconditions

If I retry it, I get this:

Module Administration
Please wait while module actions are performed

(and nothing happens)

NOTE: if I uninstall the “disabled pending upgrade” module, and then install it, it works! I hadn’t wanted to do this, since i was using an IVR and a time condition, and uninstalling it requires me to redo that part of the config, but no choice i guess. it seems like these modules had something about their state halfway in limbo…

I spoke too soon. I thought this had worked, but when I tried to re-add the IVR and TC, I made a test call, and… nothing. goes straight to vmail since dialparties.agi complains it can’t find any extensions to call. i’ve tried everything i can think of and no luck. i had to fall back to my backup of yesterday :frowning:

agi debug is always useful when dialparties.agi tells you that. It sounds like you may have somehow blown away your AMPUSER database in astdb. what happens if you go to that extension you are trying to call, and resubmit it so that it gets properly generated - can you then call it?

I tried deleting and recreating it to no avail. I’ve now got things stable, but unable to upgrade:

Time Conditions

and unable to enable
Parking Lot

In all of the failure cases, output starts getting sent to the browser window and stops in the middle, and no red UPDATE bar. Is there any way I can find out what is going on so I can provide useful input?


In trying to narrow in on this, I went to the freepbx directory and did the usual update forcing to 2.2.0 as you said. guess what? suddenly dialparties.agi is borked again. i made inbound calls with and without the bad setup and it prints the same exact information up until a certain point- in the bad case, it just returns, in the good case, it keeps going and prints more info.

I’m suspecting something corrupted or inconsistent on my end. I got totally b0rked yesterday while attempting to install SVN of asterisk 1.4 and fell back to 1.4.5. maybe something there? anyway, i’ve upgraded core and it works, announcements always seems to fail…


I did a restore to previous working config and stepped thru, doing one module at a time. The three that always fail (and the others are okay I think) are:

Time Conditions

shouldn’t be anything new/different in those modules that would have changed wrt to 1.4.

However - I’m doing everything on 1.2 since step 1 is to get all the infrastructure changes going properly on 1.2 which we know works with FreePBX, then start looking into reports and issues, as they come up, wrt to 1.4.

So … my general comment, and I will be asking this of everyone, is that if you report 1.4 issues, where appropriate, try and check the behavior on an Asterisk 1.2 base and verify if the issue exists there or not.