Guys,
After a few hours I am stymied.
I have EVE-NG running on ESXi. I can run a Dynamips image for example but not an IOL image on the GUI.
Runnnig the wrapper on the CLI I get:
Cannot listen at AF_UNIX (577). ERR: Cannot open AF_UNIX sockets (2).
Failed to create AF_UNIX socket file (2).
Caught SIGTERM, killing child.
The iousrc file is correct and the /tmp has the following permissions:
drwxrwxrwt 11 root root 4096 Mar 13 23:39 tmp
The IOL image runs correctly if I follow the procedure to test it:
cd /opt/unetlab/addons/iol/bin
touch NETMAP
LD_LIBRARY_PATH=/opt/unetlab/addons/iol/lib /opt/unetlab/addons/iol/bin/<iosname.bin> 1
The IOL image runs without a problem.
The reason here is the creation of the AF_UNIX socket.
The version is:
eve-ng 2.0.3-86 amd64
The question is why cannot the AF_UNIX socket be created. It should do it under /tmp but perhaps it is trying to do so under a different folder but what folder?
Any help will be appreciate it.
ERR: Cannot open AF_UNIX sockets (2)
Moderator: mike
-
- Posts: 533
- Joined: Wed Mar 15, 2017 1:54 pm
Re: ERR: Cannot open AF_UNIX sockets (2)
socket files are created under /tmp/netio_xxxx
E.
E.
-
- Posts: 5
- Joined: Mon Mar 12, 2018 9:26 pm
Re: ERR: Cannot open AF_UNIX sockets (2)
Well it makes sense that it will be created under tmp which is.
So digging a but more, took a look at the wrapper.txt under:
/opt/unetlab/tmp
It plainly says:
ERR File 'iourc' does not exist.
But the file exists.
drwxr-xr-x 2 root root 4096 Mar 14 16:43 .
drwxr-xr-x 4 root root 4096 Dec 16 01:07 ..
-rw-r--r-- 1 root root 1609 Mar 13 22:53 CiscoKeyGen.py
-rwxr-xr-x 1 root root 159350476 Mar 13 20:42 i86bi_linux-adventerprisek9-ms.154-2.T4.bin
-rwxr-xr-x 1 root root 103040504 Mar 13 21:01 i86bi_linux_l2-adventerprisek9-ms.156-0.9.S.bin
-rw-rw-r-- 1 root root 37 Mar 13 22:53 iourc
-rw-r--r-- 1 root root 812 Mar 14 16:42 NETMAP
-rw-r----- 1 root root 1048576 Mar 14 16:43 nvram_00032
-rw-r--r-- 1 root root 990 Mar 13 20:30 script.py
Furthermore if i run the command that EVE is attempting form the withing the directory /opt/unetlab/addons/iol/bin/
/opt/unetlab/wrappers/iol_wrapper -T 0 -D 2 -t "R2" -F /opt/unetlab/addons/iol/bin/i86bi_linux_l2-adventerprisek9-ms.156-0.9.S.bin -d 0 -e 1 -s 0 -- -n 1024 -q -m 1024 > /opt/unetlab/tmp/0/05ed6564-9c11-4060-af83-ebce194a3dfd/2/wrapper.txt 2>&1 &
It runs fine and I can console to the device and on the GUI I can see the device as started.
So the question is why using the GUI it cannot see the iourc file to start the device. And I have tried chmod 666, chmod 777 for iourc.
Ideas?
So digging a but more, took a look at the wrapper.txt under:
/opt/unetlab/tmp
It plainly says:
ERR File 'iourc' does not exist.
But the file exists.
drwxr-xr-x 2 root root 4096 Mar 14 16:43 .
drwxr-xr-x 4 root root 4096 Dec 16 01:07 ..
-rw-r--r-- 1 root root 1609 Mar 13 22:53 CiscoKeyGen.py
-rwxr-xr-x 1 root root 159350476 Mar 13 20:42 i86bi_linux-adventerprisek9-ms.154-2.T4.bin
-rwxr-xr-x 1 root root 103040504 Mar 13 21:01 i86bi_linux_l2-adventerprisek9-ms.156-0.9.S.bin
-rw-rw-r-- 1 root root 37 Mar 13 22:53 iourc
-rw-r--r-- 1 root root 812 Mar 14 16:42 NETMAP
-rw-r----- 1 root root 1048576 Mar 14 16:43 nvram_00032
-rw-r--r-- 1 root root 990 Mar 13 20:30 script.py
Furthermore if i run the command that EVE is attempting form the withing the directory /opt/unetlab/addons/iol/bin/
/opt/unetlab/wrappers/iol_wrapper -T 0 -D 2 -t "R2" -F /opt/unetlab/addons/iol/bin/i86bi_linux_l2-adventerprisek9-ms.156-0.9.S.bin -d 0 -e 1 -s 0 -- -n 1024 -q -m 1024 > /opt/unetlab/tmp/0/05ed6564-9c11-4060-af83-ebce194a3dfd/2/wrapper.txt 2>&1 &
It runs fine and I can console to the device and on the GUI I can see the device as started.
So the question is why using the GUI it cannot see the iourc file to start the device. And I have tried chmod 666, chmod 777 for iourc.
Ideas?
-
- Posts: 533
- Joined: Wed Mar 15, 2017 1:54 pm
Re: ERR: Cannot open AF_UNIX sockets (2)
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions
-
- Posts: 5
- Joined: Mon Mar 12, 2018 9:26 pm
SOLVED:ERR: Cannot open AF_UNIX sockets (2)
Deleted and re-added the devices in the lab in question. This fixed the issue eventually.