[Home]

Summary:ASTERISK-12666: [patch] Commands issued to asterisk using a remote console on OSX have no effect
Reporter:Alistair Galbraith (agalbraith)Labels:
Date Opened:2008-08-30 12:30:38Date Closed:2009-03-18 09:39:07
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Portability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) darwin.patch
Description:When starting Asterisk using either 'launchctl' or from a prommpt, it becomes impossible to issue commands using a remote (asterisk -r) connection.

Commands entered simply return to the CLI prompt.

The remote console *is* connected, because if the command "stop now" is issued to the local console, the console disconnects.

This appears to be a recurrance of bug 0011928, however I've tried both with and without the patch - and this behavior is consistent.
Comments:By: Mark Michelson (mmichelson) 2008-08-30 15:59:54

When you tried using the patch from ASTERISK-11379, did you re-run configure with "--enable-internal-poll" as one of the command line arguments?
By: Alistair Galbraith (agalbraith) 2008-08-30 22:55:17

Yes, I did. I then ran "make clean", "make install". It didn't seem to make any difference.

I did get two warnings when trying to apply the patch, however. I just assumed that the patch had actually been incorporated into the codeline now.
By: Leif Madsen (lmadsen) 2009-02-27 16:45:31.000-0600

This issue looks to be pretty old now. Just pinging it!

Still an issue on latest SVN?
By: Russell Bryant (russell) 2009-02-27 18:55:44.000-0600

This is probably still an issue, but I haven't tried it in a long time.  It has just never made it high enough on my priority list to deal with.

The last time I worked on this, I tracked it down to the code running poll() on the unix socket used to send commands to the main Asterisk instance and receive the console output never detected input on the socket.

I'm not sure if it's a bug in poll() / select() on OSX or something weird that we're doing.  The same code is working fine on other platforms.
By: vadim (vadim) 2009-03-12 08:48:31

I've tried to investigate this issue some more,
with the current trunk Rev: 181371
So i've built with --enable-internal-poll
and tried to put a breakpoint with gdb in the while running asterisk  -r.

The problem is that breakpoint is NEVER reached...
By: vadim (vadim) 2009-03-14 13:49:55

I did some more debugging and see extremely strange stuff:

main/poll.c is built and linked with the application,
but when asterisk calls poll it goes straight to the original syscall...
the darwin.patch solves the problem
By: Russell Bryant (russell) 2009-03-16 11:14:26

vadim, thanks a lot for your investigation into this issue.

I am no longer able to reproduce this myself, so can you test the code in this branch and ensure that it fixes the problem for you?

$ svn co http://svn.digium.com/svn/asterisk/team/russell/poll_compat

The branch is based on Asterisk 1.4, but similar changes would go into trunk and the 1.6 branches, as well.
By: vadim (vadim) 2009-03-16 16:40:09

I confirm it works
By: Russell Bryant (russell) 2009-03-17 07:37:12

Thanks for testing, vadim!

The code is now on reviewboard:

http://reviewboard.digium.com/r/198/
By: Digium Subversion (svnbot) 2009-03-17 21:09:14

Repository: asterisk
Revision: 182810

U   branches/1.4/apps/app_mp3.c
U   branches/1.4/apps/app_nbscat.c
U   branches/1.4/channels/chan_alsa.c
U   branches/1.4/channels/chan_skinny.c
U   branches/1.4/configure
U   branches/1.4/configure.ac
U   branches/1.4/include/asterisk/autoconfig.h.in
U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/include/asterisk/io.h
U   branches/1.4/include/asterisk/poll-compat.h
U   branches/1.4/main/Makefile
U   branches/1.4/main/asterisk.c
U   branches/1.4/main/channel.c
U   branches/1.4/main/io.c
U   branches/1.4/main/manager.c
U   branches/1.4/main/poll.c
U   branches/1.4/main/utils.c
U   branches/1.4/res/res_agi.c

------------------------------------------------------------------------
r182810 | russell | 2009-03-17 21:09:14 -0500 (Tue, 17 Mar 2009) | 44 lines

Fix cases where the internal poll() was not being used when it needed to be.

We have seen a number of problems caused by poll() not working properly on
Mac OSX.  If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues.  In Asterisk, we've
had poll.c which implements poll() using select() internally.  However, we
were still getting reports of problems.

vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.  
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.

The changes are:

1) Remove logic for when internal poll should be used from the Makefile.  
  Instead, put it in the configure script.  The logic in the configure
  script is the same as it was in the Makefile.  Ideally, we would have
  a functionality test for the problem, but that's not actually possible,
  since we would have to be able to run an application on the _target_
  system to test poll() behavior.

2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
  is not defined.

3) Change uses of poll() throughout the source tree to ast_poll().  I feel
  that it is good practice to give the API call a new name when we are
  changing its behavior and not using the system version directly in all cases.
  So, normally, ast_poll() is just redefined to poll().  On systems where
  AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().

4) Change poll() in main/poll.c to be ast_internal_poll().

It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before).  So, for example, out of tree modules that are
using poll() will not stop working or anything.  However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.

(closes issue ASTERISK-12666)
Reported by: agalbraith
Tested by: russell, vadim

http://reviewboard.digium.com/r/198/

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

http://svn.digium.com/view/asterisk?view=rev&revision=182810
By: Digium Subversion (svnbot) 2009-03-17 21:28:56

Repository: asterisk
Revision: 182847

_U  trunk/
U   trunk/apps/app_mp3.c
U   trunk/apps/app_nbscat.c
U   trunk/channels/chan_alsa.c
U   trunk/channels/chan_skinny.c
U   trunk/configure
U   trunk/configure.ac
U   trunk/include/asterisk/autoconfig.h.in
U   trunk/include/asterisk/channel.h
U   trunk/include/asterisk/io.h
U   trunk/include/asterisk/poll-compat.h
U   trunk/main/Makefile
U   trunk/main/asterisk.c
U   trunk/main/channel.c
U   trunk/main/io.c
U   trunk/main/poll.c
U   trunk/main/utils.c
U   trunk/res/res_agi.c

------------------------------------------------------------------------
r182847 | russell | 2009-03-17 21:28:56 -0500 (Tue, 17 Mar 2009) | 52 lines

Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines

Fix cases where the internal poll() was not being used when it needed to be.

We have seen a number of problems caused by poll() not working properly on
Mac OSX.  If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues.  In Asterisk, we've
had poll.c which implements poll() using select() internally.  However, we
were still getting reports of problems.

vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.  
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.

The changes are:

1) Remove logic for when internal poll should be used from the Makefile.  
  Instead, put it in the configure script.  The logic in the configure
  script is the same as it was in the Makefile.  Ideally, we would have
  a functionality test for the problem, but that's not actually possible,
  since we would have to be able to run an application on the _target_
  system to test poll() behavior.

2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
  is not defined.

3) Change uses of poll() throughout the source tree to ast_poll().  I feel
  that it is good practice to give the API call a new name when we are
  changing its behavior and not using the system version directly in all cases.
  So, normally, ast_poll() is just redefined to poll().  On systems where
  AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().

4) Change poll() in main/poll.c to be ast_internal_poll().

It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before).  So, for example, out of tree modules that are
using poll() will not stop working or anything.  However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.

(closes issue ASTERISK-12666)
Reported by: agalbraith
Tested by: russell, vadim

http://reviewboard.digium.com/r/198/

........

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

http://svn.digium.com/view/asterisk?view=rev&revision=182847
By: Digium Subversion (svnbot) 2009-03-18 09:24:29

Repository: asterisk
Revision: 182945

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_mp3.c
U   branches/1.6.0/apps/app_nbscat.c
U   branches/1.6.0/channels/chan_alsa.c
U   branches/1.6.0/channels/chan_skinny.c
U   branches/1.6.0/configure
U   branches/1.6.0/configure.ac
U   branches/1.6.0/include/asterisk/autoconfig.h.in
U   branches/1.6.0/include/asterisk/channel.h
U   branches/1.6.0/include/asterisk/io.h
U   branches/1.6.0/include/asterisk/poll-compat.h
U   branches/1.6.0/main/Makefile
U   branches/1.6.0/main/asterisk.c
U   branches/1.6.0/main/channel.c
U   branches/1.6.0/main/io.c
U   branches/1.6.0/main/poll.c
U   branches/1.6.0/main/utils.c
U   branches/1.6.0/res/res_agi.c

------------------------------------------------------------------------
r182945 | russell | 2009-03-18 09:24:28 -0500 (Wed, 18 Mar 2009) | 60 lines

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

................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines

Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines

Fix cases where the internal poll() was not being used when it needed to be.

We have seen a number of problems caused by poll() not working properly on
Mac OSX.  If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues.  In Asterisk, we've
had poll.c which implements poll() using select() internally.  However, we
were still getting reports of problems.

vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.  
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.

The changes are:

1) Remove logic for when internal poll should be used from the Makefile.  
  Instead, put it in the configure script.  The logic in the configure
  script is the same as it was in the Makefile.  Ideally, we would have
  a functionality test for the problem, but that's not actually possible,
  since we would have to be able to run an application on the _target_
  system to test poll() behavior.

2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
  is not defined.

3) Change uses of poll() throughout the source tree to ast_poll().  I feel
  that it is good practice to give the API call a new name when we are
  changing its behavior and not using the system version directly in all cases.
  So, normally, ast_poll() is just redefined to poll().  On systems where
  AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().

4) Change poll() in main/poll.c to be ast_internal_poll().

It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before).  So, for example, out of tree modules that are
using poll() will not stop working or anything.  However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.

(closes issue ASTERISK-12666)
Reported by: agalbraith
Tested by: russell, vadim

http://reviewboard.digium.com/r/198/

........

................

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

http://svn.digium.com/view/asterisk?view=rev&revision=182945
By: Digium Subversion (svnbot) 2009-03-18 09:32:48

Repository: asterisk
Revision: 182946

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_mp3.c
U   branches/1.6.1/apps/app_nbscat.c
U   branches/1.6.1/channels/chan_alsa.c
U   branches/1.6.1/channels/chan_skinny.c
U   branches/1.6.1/configure
U   branches/1.6.1/configure.ac
U   branches/1.6.1/include/asterisk/autoconfig.h.in
U   branches/1.6.1/include/asterisk/channel.h
U   branches/1.6.1/include/asterisk/io.h
U   branches/1.6.1/include/asterisk/poll-compat.h
U   branches/1.6.1/main/Makefile
U   branches/1.6.1/main/asterisk.c
U   branches/1.6.1/main/channel.c
U   branches/1.6.1/main/io.c
U   branches/1.6.1/main/poll.c
U   branches/1.6.1/main/utils.c
U   branches/1.6.1/res/res_agi.c

------------------------------------------------------------------------
r182946 | russell | 2009-03-18 09:32:48 -0500 (Wed, 18 Mar 2009) | 60 lines

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

................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines

Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines

Fix cases where the internal poll() was not being used when it needed to be.

We have seen a number of problems caused by poll() not working properly on
Mac OSX.  If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues.  In Asterisk, we've
had poll.c which implements poll() using select() internally.  However, we
were still getting reports of problems.

vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.  
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.

The changes are:

1) Remove logic for when internal poll should be used from the Makefile.  
  Instead, put it in the configure script.  The logic in the configure
  script is the same as it was in the Makefile.  Ideally, we would have
  a functionality test for the problem, but that's not actually possible,
  since we would have to be able to run an application on the _target_
  system to test poll() behavior.

2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
  is not defined.

3) Change uses of poll() throughout the source tree to ast_poll().  I feel
  that it is good practice to give the API call a new name when we are
  changing its behavior and not using the system version directly in all cases.
  So, normally, ast_poll() is just redefined to poll().  On systems where
  AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().

4) Change poll() in main/poll.c to be ast_internal_poll().

It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before).  So, for example, out of tree modules that are
using poll() will not stop working or anything.  However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.

(closes issue ASTERISK-12666)
Reported by: agalbraith
Tested by: russell, vadim

http://reviewboard.digium.com/r/198/

........

................

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

http://svn.digium.com/view/asterisk?view=rev&revision=182946
By: Digium Subversion (svnbot) 2009-03-18 09:39:06

Repository: asterisk
Revision: 182947

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_mp3.c
U   branches/1.6.2/apps/app_nbscat.c
U   branches/1.6.2/channels/chan_alsa.c
U   branches/1.6.2/channels/chan_skinny.c
U   branches/1.6.2/configure
U   branches/1.6.2/configure.ac
U   branches/1.6.2/include/asterisk/autoconfig.h.in
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/include/asterisk/io.h
U   branches/1.6.2/include/asterisk/poll-compat.h
U   branches/1.6.2/main/Makefile
U   branches/1.6.2/main/asterisk.c
U   branches/1.6.2/main/channel.c
U   branches/1.6.2/main/io.c
U   branches/1.6.2/main/poll.c
U   branches/1.6.2/main/utils.c
U   branches/1.6.2/res/res_agi.c

------------------------------------------------------------------------
r182947 | russell | 2009-03-18 09:39:05 -0500 (Wed, 18 Mar 2009) | 60 lines

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

................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines

Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines

Fix cases where the internal poll() was not being used when it needed to be.

We have seen a number of problems caused by poll() not working properly on
Mac OSX.  If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues.  In Asterisk, we've
had poll.c which implements poll() using select() internally.  However, we
were still getting reports of problems.

vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.  
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.

The changes are:

1) Remove logic for when internal poll should be used from the Makefile.  
  Instead, put it in the configure script.  The logic in the configure
  script is the same as it was in the Makefile.  Ideally, we would have
  a functionality test for the problem, but that's not actually possible,
  since we would have to be able to run an application on the _target_
  system to test poll() behavior.

2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
  is not defined.

3) Change uses of poll() throughout the source tree to ast_poll().  I feel
  that it is good practice to give the API call a new name when we are
  changing its behavior and not using the system version directly in all cases.
  So, normally, ast_poll() is just redefined to poll().  On systems where
  AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().

4) Change poll() in main/poll.c to be ast_internal_poll().

It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before).  So, for example, out of tree modules that are
using poll() will not stop working or anything.  However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.

(closes issue ASTERISK-12666)
Reported by: agalbraith
Tested by: russell, vadim

http://reviewboard.digium.com/r/198/

........

................

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

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