Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

app_python3 threading exceptions on startup #1916

Closed
weili-jiang opened this issue Mar 31, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@weili-jiang
Copy link

commented Mar 31, 2019

Description

When Kamailio starts up with app_python3 enabled, multiple threading exceptions appear in the log after forking. The same setup previously using app_python2 exhibits no such errors.

Expected behavior

When Kamailio starts up with app_python3 enabled, everything is successful.

Actual observed behavior

When Kamailio starts up with app_python3 enabled, exceptions in the Python interpreter are logged.

Debugging Data

Error examples:

Exception ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 1323, in _after_fork

And

    _active_limbo_lock = _allocate_lock()
SystemError: <built-in function allocate_lock> returned a result with an error set

Log Messages

dump.log

Note: xxx fields have been redacted as they contain proprietary data.

SIP Traffic

N/A

Possible Solutions

The errors may or may not be benign (and thus safe to ignore) - KEMI routing still appears to work.

Additional Information

  • Kamailio Version - output of kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown 
compiled with gcc 6.3.0
  • Operating System:

Debian GNU/Linux 9 (stretch)

Linux 4e0ff3e84062 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 GNU/Linux
@aalba6675

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2019

  1. Does your routing script use threading or indirectly via python modules which use threading?

  2. Can you reproduce this if you modify the logic to only initialize the threading bits after fork i.e. rank>0?

  3. Don't initialize logic that uses threading pre fork().

@weili-jiang

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

We do not use threading from our KEMI script and do not import any Python modules that use threading. The Python is all just parsing and routing logic for Kamailio's own modules.

@miconda

This comment has been minimized.

Copy link
Member

commented May 22, 2019

I just started kamailio master branch with app_python3, using the python routing script from source tree misc/examples/kemi/kamailio-basic-kemi-python.py. It started fine, so likely you face something related to a python extension you are using. It doesn't seem to have a relation to the C code in Kamailio, therefore I suggest to start a discussion on sr-users [at] lists.kamailio.org mailing list to identify the problem, there are many more people using Python then those in the development team.

For not this item is going to be closed, if proves to be something in the code after sorting out on sr-users, then it can be reopened.

@miconda miconda closed this May 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.