BUG "Symlink from modules failed " after fresh install

[titodj]

I have a fresh install of PIAF 2.0.6.4 FreePBX 2.11.0.10 Asterisk 11.5.0

And get this error.

retrieve_conf failed to sym link:
/etc/asterisk/logger.conf from logfiles/etc (Already exists, linked to something else)
This can result in FATAL failures to your PBX. If the target file exists and not identical, the symlink will not occur and you should rename the target file to allow the automatic sym link to occur and remove this error, unless this is an intentional customization.
Added 4 minutes ago
(retrieve_conf.SYMLINK)

I google it, and found, and try this, freepbx.org/forum/beta-program-issues/symlink-from-modules-failed

But still get the error..

Should I just disregard it?

 

[wardmundy]

mv /etc/asterisk/logger.conf /etc/asterisk/logger.conf.old
amportal restart

 

[titodj]

Thank's Ward, what I was failing to do, was restarting asterisk.

 

[tm1000]

I think we finally fixed this in the newest framework (not sure if we released it yet though)

 

[Brian Simmons]

FYI - I just installed PIAF-Green and got this same error....

 

[wardmundy]

Use the magic trick to solve symlink errors (insert name of file causing problem) until FreePBX gets this straightened out.

 

[mcbsys]

I'm getting this on the logger.conf symlink after updating FreePBX 2.10.

I renamed logger.conf and ran amportal restart. At the SETTING FILE PERMISSIONS stage, I see this in the console: "chmod: cannot operate on dangling symlink `/var/lib/asterisk/bin/fax-process.pl'". I'm not using the fax module so I guess I can ignore that? Anyway, the the symlink message is still in the System Status page but from 45 minutes ago.

According to p_lindheimer,

restarting asterisk has nothing to do with it. The error is detected and reported, or deleted when retrieve_conf runs, and only then. That is what "apply configuration changes" does, it runs retrieve_conf and then does a module reload in Asterisk afterwards (but the latter is not related).

Since I don't have a red "Apply Config" button, I went to Other > Config Edit and clicked Re-read Configs, which I thought did the same thing. The message is still there. So I went to some random config page, clicked Submit (without changing anything), then clicked on the red Apply Config button. Symlink message is still there, from 51 minutes ago.

I see that the logger.conf file has been recreated and is still linking to /.../html/admin/modules/logfiles/etc/logger.conf, which begins with "Do NOT edit this file as it is auto-generated by FreePBX."

Here's my configuration as shown at login:

PIAF Installed Version = 2.0.6.2 under *HARDWARE*
FreePBX Version = 2.10.1.16
2.10
Running Asterisk Version = 1.8.11-cert2
Asterisk Source Version = 1.8.11-cert2
Dahdi Source Version = 2.6.1+2.6.1
Libpri Source Version = 1.4.12
Operating System = CentOS release 6.2 (Final)
Kernel Version = 2.6.32-220.17.1.el6.i686 - 32 Bit

What to do? Reboot?

 

[Hyksos]

Can you further upgrade the "framework" module? Is module admin reporting the framework module to be the most up to date possible?

 

[Hyksos]

And provide the result of:

find /var/www/html/ -type f -name "*logger*"

 

[mcbsys]

From Module Admin:

FreePBX Framework - 2.10.1.16 - Enabled and up to date

I'd have to upgrade to 2.11 to go further, which I'm not opposed to but will probably want to do a full system backup first.

$find /var/www/html/ -type f -name "*logger*"
/var/www/html/admin/modules/logfiles/etc/logger.conf
/var/www/html/admin/modules/core/etc/logger.conf

 

[Hyksos]

is the core module fully up to date?

 

[mcbsys]

Yes. This happened after an Upgrade All this morning. Something like 29 modules upgraded.

 

[mcbsys]

Decided to try a full server reboot. The message is still there.

 

[Hyksos]

mv /var/www/html/admin/modules/core/etc/logger.conf /root/logger.conf
amportal restart
amportal a r

 

[mcbsys]

I tried a local rename (not moving to root) along with the deleting /etc/asterisk/logger.conf symlink. Still had the message but it mentioned /etc/asterisk/logger.conf.old. Realized I may have missed subtle changes in the message so I'm trying to start over:

/var/www/html/admin/modules/core/etc/logger.conf exists as a text file

/etc/asterisk/logger.conf exists as a link to that file

/etc/asterisk/logger.conf.old does not exist

amportal restart
amportal a r

Now the message says

retrieve_conf failed to sym link: 
   /etc/asterisk/logger.conf from core/etc (Already exists, linked to something else)

Can someone explain what this means? Would like to understand what I'm doing, not just blindly rename files.

Thanks for your help!

 

[wardmundy]

It means you still have a file named logger.conf in the /etc/asterisk directory. It has to be renamed or deleted.

 

[mcbsys]

Well the rename didn't work earlier--see post #7 in this thread. I'm pretty sure the message originally said "from logfiles/etc" but now it says "from core/etc". I thought maybe if I understood what is supposed to be linked to what, I could figure out where the chain is broken.

 

[Hyksos]

you say it's not your cup of tea yet you modify help instructions...
Let's try again.

mv /var/www/html/admin/modules/core/etc/logger.conf /root/logger.conf
unlink /etc/asterisk/logger.conf
amportal a r

 

[mcbsys]

Hyksos, yes thank you, your modified instructions worked. Renaming the file instead of moving to root also worked. The new unlink command helped.

Through some trial an error, here is what I think is going on. Can someone confirm?

When FreePBX loads its configs, it wants to find or create a symbolic link from /etc/asterisk/logger.conf to the actual logger.conf file that it should use. It looks in two places for logger.conf:

/var/www/html/admin/modules/core/etc
/var/www/html/admin/modules/logfiles/etc

If logger.conf exists in both places, it will try to create the symbolic link twice, and the second attempt will fail. To solve this, you need to move or rename one of the logger.conf files and delete the old symbolic link. When you reload the configs, FreePBX will only try to create the link once and no further symlink warning should occur.

I prefer to keep backups of old files in their original folder rather than at /root, so I would suggest:

mv /var/www/html/admin/modules/core/etc/logger.conf /var/www/html/admin/modules/core/etc/logger.conf.old
unlink /etc/asterisk/logger.conf
amportal a r

 

[Hyksos]

I prefer moving it out for precisely the hiccup you had, but you made it work!
It's exactly what's going on.
It got moved from core to logfiles module, but I though a fix had been made for that in subsequent updates.
You now have to consider more research to confirm no other issue will popup after such a crude fix

2.11 is fine fine fine if you ask me, but I also believe that updating is bad in most cases unless you're missing a feature or fix.
But you decided to upgrade already since this is what caused this, so if you're gonna do it, I would do it all way. That's an opinion, of course.

But what was the reason for upgrading in the first place, you never said?