Error Asterisk Service not working properly

Hello, I have an asterisk server, I have it perfectly configured, I make calls perfectly from mobile to desktop computer.

I want to pass the asterisk to my laptop, when I pass it to the laptop through a hard disk when trying to start asterisk, I get an error that lsb has not started, at first I thought it was because of the IP that I did not have a fixed IP defined, then I deleted The copied machine, I went to the original one, I added an interface in which I would provide the intrenet and another interface in which it would be fixed giving operation to the asterisk, I test it on the desktop and it works but when I pass it back to the porttail it fails and it does not because it is the problem

error: See “systemctl status asterisk.service” and “journalctl -xe” for details.
root@swarm3:~# service asterisk status
● asterisk.service - LSB: Asterisk PBX
Loaded: loaded (/etc/init.d/asterisk; generated)
Active: failed (Result: exit-code) since Sat 2021-02-27 01:00:22 CET; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 629 ExecStart=/etc/init.d/asterisk start (code=exited, status=132)

feb 27 01:00:22 swarm3 systemd[1]: Starting LSB: Asterisk PBX…
feb 27 01:00:22 swarm3 asterisk[629]: Starting Asterisk PBX: asteriskIllegal instruction
feb 27 01:00:22 swarm3 systemd[1]: asterisk.service: Control process exited, code=exited, status=132
feb 27 01:00:22 swarm3 systemd[1]: asterisk.service: Failed with result ‘exit-code’.
feb 27 01:00:22 swarm3 systemd[1]: Failed to start LSB: Asterisk PBX.
lines 1-11/11 (END)

132 probably means killed with signal 4, which is an illegal instruction trap. That would typically result from compiling Asterisk for a specific processor type and then running it on a less capable processor. (I’m assuming the 132 is 128, for core dumped, plus 4, for SIGILL. The core dump, when processed through gdb, should tell you more.

1 Like

which -a asterisk | xargs file

may yield a clue.

1 Like

I get this:

root@swarm3:~# which -a asterisk | xargs file
/usr/sbin/asterisk: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7e2946953aad1b1d93a3f1321f5f343e8e158871, with debug_info, not stripped
/sbin/asterisk: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7e2946953aad1b1d93a3f1321f5f343e8e158871, with debug_info, not stripped

You mean, since I have programmed asterisk on a more powerful desktop computer by passing it on a porttail with less capacity, it happens that it doesn’t turn on asterisk?

It is not power in terms or raw speed. It is in terms of the machine instructions that can be executed.

It will start to run, but when it tries to execute an instruction that isn’t implemented on the new target machine, it will fail.

To avoid this you need to build for the lowest common denominator, and, in particular, disable build native. I believe the build process defaults to taking advantage of all features found on the machine on which it was compiled.

1 Like

Asterisk installation package is designed for OS services environment, current OS versions are based on SystemCTL it leads with this kind of issues. Although as there posts and resources about script examples to include asterisk in SystemCTL environment it doesn`t work.

1 Like

I overlooked that the logs explicitly say it was an illegal instruction, so one doesn’t have to deconstruct the status code. I’d say it was definitely the result of running a version optimised for a particular processor type on a different processor type.

1 Like

Thanks, it worked for me, use a script to solve it, thank you very much for helping me understand Asterisk a little more

Thanks, please be aware about securities issues to prevent hackers and others.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.