[Home]

Summary:ASTERISK-12056: sip reload doesn't add new peers
Reporter:Marcelo M. Sosa Lugones (marsosa)Labels:
Date Opened:2008-05-20 19:08:26Date Closed:2008-05-20 21:15:39
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I'm testing 1.6.0beta8 and beta9 and in both versions i have the same problem: when i add new peers to a file included in sip.conf and then do a sip reload (or full reload) the new peer doesn't appears to be added until a full restart.
Comments:By: Marcelo M. Sosa Lugones (marsosa) 2008-05-20 19:11:20

It seems very strange that no one had noticed this before, so i'm assuming it is a problem of my configuration, but it is pretty simple, and it worked fine with 1.4, i have a sip.conf that #include a file named sip.peers.conf. The debug doesn't show anything useful, the only line i get in the debug file is "reloading sip".

[May 19 23:08:32] VERBOSE[23199] logger.c:  Reloading SIP
[May 19 23:08:32] DEBUG[23199] chan_sip.c: --------------- Done destroying pruned peers
[May 19 23:08:32] DEBUG[23199] chan_sip.c: --------------- SIP reload done
By: Mark Michelson (mmichelson) 2008-05-20 19:31:07

I attempted reproducing this but I was unsuccessful. In my test, I had the following line at the top of sip.conf

#include sip.conf2

In sip.conf, I have 6 peers defined, and in sip.conf2, I have 1 peer defined.

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status              
5000/5000                  (Unspecified)    D          0        Unmonitored          
4000/4000                  (Unspecified)    D          0        Unmonitored          
3000/3000                  (Unspecified)    D          0        Unmonitored          
2001/2001                  10.19.4.251      D          5060     Unmonitored          
1000/1000                  (Unspecified)    D          0        Unmonitored          
2000/2000                  10.19.3.253      D          5060     Unmonitored          
6000                       (Unspecified)               5060     Unmonitored          
7 sip peers [Monitored: 0 online, 0 offline Unmonitored: 3 online, 4 offline]

I then modify sip.conf2 to have a new peer (called 600) and issue a "sip reload" and "sip show peers"

*CLI>  Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
 == Parsing '/etc/asterisk/sip.conf2': Found
 == Parsing '/etc/asterisk/users.conf': Found
 == Parsing '/etc/asterisk/sip_notify.conf': Found
*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status              
5000/5000                  (Unspecified)    D          0        Unmonitored          
4000/4000                  (Unspecified)    D          0        Unmonitored          
3000/3000                  (Unspecified)    D          0        Unmonitored          
2001/2001                  10.19.4.251      D          5060     Unmonitored          
1000/1000                  (Unspecified)    D          0        Unmonitored          
2000/2000                  10.19.3.253      D          5060     Unmonitored          
600/600                    10.19.2.205      D          5060     Unmonitored          
6000                       (Unspecified)               5060     Unmonitored          
8 sip peers [Monitored: 0 online, 0 offline Unmonitored: 4 online, 4 offline]

As you can see, peer 600 was added to the list.

Could you give more details about your configuration? Are there any other extra steps I'm leaving out in trying to reproduce the failure?


By: Marcelo M. Sosa Lugones (marsosa) 2008-05-20 19:38:53

Thanks for your reply.
No other steps where taken, i'll trim the sip.conf file to a minimum (now it basically the default config and a "#include sip.peers.conf" at the bottom.

One strange thing i've just noticed:

pbx-netlp*CLI> reload chan_sip.so
   -- Reloading module 'chan_sip.so' (Session Initiation Protocol (SIP))
Reloading SIP
pbx-netlp*CLI> sip reload
Reloading SIP
pbx-netlp*CLI> core set verbose 100
Verbosity was 3 and is now 100
pbx-netlp*CLI> sip reload
Reloading SIP
pbx-netlp*CLI>

I don't have any "parsing ... " line...
By: Mark Michelson (mmichelson) 2008-05-20 19:40:51

As a second test, I defined all my peers inside of sip.conf2 and tried the same test. It was still successful.
By: Marcelo M. Sosa Lugones (marsosa) 2008-05-20 19:47:21

Another strange thing related to this:

pbx-netlp*CLI> sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf':  == Found
 == Parsing '/etc/asterisk/sip.peers.conf':  == Found
 == Parsing '/etc/asterisk/users.conf':  == Found
   -- Added authentication for realm cenip
 == Parsing '/etc/asterisk/sip_notify.conf':  == Found
pbx-netlp*CLI> sip reload
Reloading SIP
pbx-netlp*CLI> sip reload
Reloading SIP

The sip.conf file was (almost) empty when starting asterisk, then i copy the sample conf with my #include at the end and then reloaded sip, and it worked, and then reloaded again and it didn't work this time. I'm adding the sip config to this bugfile in a few seconds after another tests.
By: Mark Michelson (mmichelson) 2008-05-20 19:48:17

Oh crud. I just realized that I forgot to actually make install when I compiled 1.6.0 a while ago to try reproducing this. I'll re-run my tests and see what's up. Sorry for the misleading notes earlier.
By: Marcelo M. Sosa Lugones (marsosa) 2008-05-20 19:51:32

ok, i think i got this...
"sip reload" works fine when the file sip.conf is changed, if i don't change sip.conf but i do change any file (even if i only append a newline) included into it, "sip reload" doesn't parse the files.
I know, i'm crazy :-(
By: Mark Michelson (mmichelson) 2008-05-20 19:54:21

Okay, I reproduced it now. I'll work on getting it fixed.
By: Marcelo M. Sosa Lugones (marsosa) 2008-05-20 19:56:33

Just for the record, i think it affects any reload, not just SIP.

Thanks.
By: Mark Michelson (mmichelson) 2008-05-20 19:57:42

The problem appears to be that the config parser thinks that sip.conf has not been changed, so it takes no action. This is obviously incorrect behavior.
By: Mark Michelson (mmichelson) 2008-05-20 20:33:39

You are quite correct that this is a core configuration parsing problem and is not  specific to SIP. I will update the categorization to reflect this.
By: Mark Michelson (mmichelson) 2008-05-20 20:50:05

Okay, I believe that I have narrowed the problem down some, and in a way it is a problem specific to sip.conf.

What happens is that res_phoneprov also parses sip.conf. The problem is that the included file is only cached in the instance when res_phoneprov parses sip.conf. As a result, when chan_sip asks to reload sip.conf, we don't check the status of the cached included file because it was not properly cached to begin with. This would happen if any configuration file is parsed by two separate source files.

A workaround for the issue is to unselect res_phoneprov in menuselect and remove res_phoneprov.so from /usr/lib/asterisk/modules/ but that is not the long-term solution.
By: Mark Michelson (mmichelson) 2008-05-20 20:55:58

All right! I made the fix and will be committing it soon. Thanks for the bug report!
By: Digium Subversion (svnbot) 2008-05-20 21:14:28

Repository: asterisk
Revision: 117367

U   trunk/main/config.c

------------------------------------------------------------------------
r117367 | mmichelson | 2008-05-20 21:14:27 -0500 (Tue, 20 May 2008) | 19 lines

Be sure that we cache included files for each source file which loads
a configuration file.  As it was, only the first did so. This led to
a problem if the included file was changed (but not the configuration
file which includes it) and the second source file attempted to reload
the configuration. It would not see that the included file had changed.

In this particular example, res_phoneprov and chan_sip both loaded
sip.conf, which included a file call sip.peers.conf. Since res_phoneprov
was the first to load sip.conf, only it cached the fact that sip.conf
included sip.peers.conf. If sip.peers.conf were changed and sip.conf were
not and a sip reload were issued (meaning that chan_sip attempts to
reload sip.conf only if it and its included files have changed) the changes
made to sip.peers.conf would not be seen and therefore no action would be
taken.

(closes issue ASTERISK-12056)
Reported by: marsosa


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=117367
By: Digium Subversion (svnbot) 2008-05-20 21:15:39

Repository: asterisk
Revision: 117368

_U  branches/1.6.0/
U   branches/1.6.0/main/config.c

------------------------------------------------------------------------
r117368 | mmichelson | 2008-05-20 21:15:38 -0500 (Tue, 20 May 2008) | 27 lines

Merged revisions 117367 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r117367 | mmichelson | 2008-05-20 21:20:31 -0500 (Tue, 20 May 2008) | 19 lines

Be sure that we cache included files for each source file which loads
a configuration file.  As it was, only the first did so. This led to
a problem if the included file was changed (but not the configuration
file which includes it) and the second source file attempted to reload
the configuration. It would not see that the included file had changed.

In this particular example, res_phoneprov and chan_sip both loaded
sip.conf, which included a file call sip.peers.conf. Since res_phoneprov
was the first to load sip.conf, only it cached the fact that sip.conf
included sip.peers.conf. If sip.peers.conf were changed and sip.conf were
not and a sip reload were issued (meaning that chan_sip attempts to
reload sip.conf only if it and its included files have changed) the changes
made to sip.peers.conf would not be seen and therefore no action would be
taken.

(closes issue ASTERISK-12056)
Reported by: marsosa


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=117368