-
Notifications
You must be signed in to change notification settings - Fork 10
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
100% cpu on raspberry pi #4
Comments
On 8 February 2013 06:59, jmls [email protected] wrote:
On the other hand, our Pi dev environment is down at present, so I cannot I do not remember ever seeing a 100% CPU issue in astmanproxy - Which Steve |
Hi Steve, thanks for the response. git status gives me "on branch master" PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND it may be some bad config or missing libs or something - but as I said, thanks again On 8 February 2013 08:00, Steve Davies [email protected] wrote:
Julian Lyndon-Smith "The bitterness of poor quality remains long after the sweetness of low Follow dot.r on http://twitter.com/DotRlimited |
On 8 February 2013 08:06, jmls [email protected] wrote:
Are you able to run astmanproxy in debug mode in the foreground
to see if it is looping in any obvious place? Failing that, run it under GDB, and interrupt it while its in the loop and Steve |
astmanproxy -dddddddddd does not produce anything I'll have a look at how to start astmanproxy with gdb and get back to you. thanks On 8 February 2013 08:10, Steve Davies [email protected] wrote:
Julian Lyndon-Smith "The bitterness of poor quality remains long after the sweetness of low Follow dot.r on http://twitter.com/DotRlimited |
Any progress here? I've got the same issue and can't find the cause :-( astmanproxy on raspberry pi 3b+ with latest raspbian would be just cool! |
Are you able to try any of the tests above to determine where it gets stuck?
I've never been able to cause this issue myself.
…On Thu, 17 Jan 2019 at 21:51, Florian Taeger ***@***.***> wrote:
Any progress here? I've got the same issue and can't find the cause :-(
astmanproxy on raspberry pi 3b+ with latest raspbian would be just cool!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA5ayPBNV0Rr9kFMJHZGRPHK4geXBldks5vEOjPgaJpZM4Aammd>
.
|
I've started astmanproxy with "astmanproxy -dddddddddd" but got no output at all. CPU load is up to 100% on one core. Nothing else. No idea where to look for the issue. |
Are you in a position to run astmanproxy under either strace, and/or gdb,
and break into it during the 100% CPU to see where it may be happening?
Can you also confirm which git branch/version you are building from?
Thanks,
Steve
…On Fri, 18 Jan 2019 at 16:27, Florian Taeger ***@***.***> wrote:
I've started astmanproxy with "astmanproxy -dddddddddd" but got no output
at all. CPU load is up to 100% on one core. Nothing else. No idea where to
look for the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA5azfmDPOFuqDzO68Fs-s8bWDcC4Lgks5vEfYOgaJpZM4Aammd>
.
|
Here is the strace output (just compiled the latest release which is 1.28.3 at the moment):
Nothing happens after this entry. At all. Like nothing ;-) |
The above strace was from the latest raspbian version. Here is a strace generated on a CentOS 7 1810 on a Raspberry Pi 3B+:
|
That looks like it is having trouble setting up TLS - That is not code I've ever used since I only allow local/internal connections on my systems. Are you using SSL? can you disable it to see if it helps? Does the same config work on a non-PI setup? Cheers, |
The exact same config works just fine on a x86 machine. Right away. I've tried to remove any ssl related config from astmanproxy but the issue is still existent. |
Maybe some output from the compiling - I think there is an issue with SSL on the way that I didn't pay attention to earlier.
root@raspberrypi:/home/pi/astmanproxy# openssl version |
So these two lines might be the issue: src/ssl.c: In function 'init_secure': |
I've never touched that code - I inherited it from the original code base.
What version of libssl do you have installed - That code is so old that it
should probably be compiled against libssl-1.0.1 but libssl-1.1 is the
current version and they may not be compatible.
The error you posted is only a warning - it SHOULD be okay.
My other thought is selinux - can you check that selinux is disabled as I
tend to find that breaks many things.
Regards,
Steve
…On Tue, 14 May 2019 at 12:51, Florian Taeger ***@***.***> wrote:
So these two lines might be the issue:
src/ssl.c: In function 'init_secure':
src/ssl.c:59:7: warning: assignment discards 'const' qualifier from
pointer target type [-Wdiscarded-qualifiers]
meth = SSLv23_server_method();
^
src/ssl.c: In function 'client_init_secure':
src/ssl.c:90:7: warning: assignment discards 'const' qualifier from
pointer target type [-Wdiscarded-qualifiers]
meth = SSLv23_client_method();
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4?email_source=notifications&email_token=AAADS26YLJ2TWXOXPFWKFQDPVKRTDA5CNFSM4ADKNGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVLHIOI#issuecomment-492205113>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAADS26V4EMF3F6DMZ6DAM3PVKRTDANCNFSM4ADKNGOQ>
.
|
Hmm. It does work just fine on a x86 machine with the same openssl version. So I guess it's something in the code that is using something special to x86 hardware. Not sure though. Is there a way to compile astmanproxy without ssl support? |
It should not be possible to write processor specific code in 'C' unless it
is something to do with the (very weird) endian-ness of the PI's CPU, which
stores 64-bit values very strangely. You can put weird parameters on the
compile line though - Are you compiling on the same device you are running
it? Or something different like a cross-compile for example? The compiler
should be compensating for all of that though.
Your best bet might be to put LOTS of extra debug lines into the source and
see what happens. How far it gets into the code before using 100% CPU. You
might be able to find exactly which line(s) it is stuck on.
I looked at our old PI build of astmanproxy from years back, and I did
nothing special in the code and it worked as far as everyone remembers.
That was probably on a PI v.1 though.
I cannot see any obvious way to disable SSL, it tries to initialise even if
it is not using it.
…On Sun, 19 May 2019 at 13:03, Florian Taeger ***@***.***> wrote:
Hmm. It does work just fine on a x86 machine with the same openssl
version. So I guess it's something in the code that is using something
special to x86 hardware. Not sure though.
Is there a way to compile astmanproxy without ssl support?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4?email_source=notifications&email_token=AAADS2ZTA7BOPYG2GVKXTHTPWE62VA5CNFSM4ADKNGO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVXAW5I#issuecomment-493751157>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAADS26R3I746PQCNJJUYVLPWE62VANCNFSM4ADKNGOQ>
.
|
when starting astmanproxy on a raspberry pi, the cpu goes to 99% cpu . Astmanproxy never manages to connect to the asterisk instance
Anyone seen this ? What steps can I take to see where the problem may be ?
We do use astmanproxy on a centos installation with no problems at all
The text was updated successfully, but these errors were encountered: