AppImage with --appimage-extract-and-run doesn't open ports
813492291816 opened this issue · 9 comments
I came across this issue attempting to run the AppImage in docker. Docker doesn't work nicely with fuse, so I had to use --appimage-extract-and-run, However, this causes a premature termination of bitmessage and the container stops.
Interestingly, I found this issue to be present outside docker and when --appimage-extract-and-run is not used. This is verified with the latest build (https://appimage.bitmessage.org/builds/5456/) and release (https://appimage.bitmessage.org/releases/20220119/).
user@box:~$ ./PyBitmessage-0.6.3.2.glibc2.15-x86_64.AppImage -d
2022-01-22 21:20:55,774 - WARNING - Using default logger configuration
Running as a daemon. Send TERM signal to end.
TerminatedIs this a known issue? Is there a workaround to get it working?
If using -d, the process daemonizes, so what you observe is the expected behaviour. Regarding docker, there is a Dockerfile included in the project root, have you tried that?
When using --appimage-extract-and-run, the order of arguments matters. You should put -d after, not before, --appimage-extract-and-run. This may be enough to fix your issue. However I don't recommend deploying the appimage inside docker, it makes little sense.
I understand you usually run foreground processes in a container and this should be addressed in PyBitmessage. There isn't a direct way to do that now in, what you could do is to comment calls to daemonize in src/bitmessagemain.py.
I currently run bitmessage in daemon mode in a docker container and it works just fine, along with several other containers, using docker-compose. This allows separation from the host system and easier install of the system bitmessage is a part of (BitChan). I was attempting to move to an AppImage to prevent having to install Python 2 and Qt4.
You should put -d after, not before, --appimage-extract-and-run
This is what I did that causes the container to stop.
Well, I found I could spawn a foreground sleep process that keeps the container running:
/usr/local/bin/pybitmessage -d & sleep infinity
Note1: pybitmessage is a symlink to the appimage.
Note2: I've moved to using the env variable APPIMAGE_EXTRACT_AND_RUN=1.
Strangely, now I can't access the API, the connection is refused. I've merely run the appimage instead of the normal linux binary, so I'm a little baffled what the issue is now, since kays.dat should be recognized since its location is set via the environment variable BITMESSAGE_HOME.
I've verified it's not an issue with the appimage, as I've been able to run it in daemon mode on my host linux system and connect to the API. So, the issue appears to be related to docker.
Update: It seems the issue is a listener is not created within the container. Using netstat -tunlp I can see the API port hasn't been set up to be listened on by bitmessage. I'm sort of had a standstill, since I can't get much information from bitmessage. Is there some way to enable more verbose output when it's starting up?
I think I found what causes the issue, it's --appimage-extract-and-run.
Note: The following is running outside docker, on a full linux distro.
When executed without --appimage-extract-and-run:
user@box:~$ ./PyBitmessage-0.6.3.2.glibc2.15-x86_64.AppImage -d
2022-01-23 00:19:42,606 - WARNING - Using default logger configuration
Running as a daemon. Send TERM signal to end.
Terminated
user@box:~$ sudo netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8444 0.0.0.0:* LISTEN 286150/././/bin/pyt
tcp 0 0 0.0.0.0:8445 0.0.0.0:* LISTEN 286150/././/bin/pyt
udp 0 0 0.0.0.0:8444 0.0.0.0:* 286150/././/bin/pyt When executed with --appimage-extract-and-run:
user@box:~$ ./PyBitmessage-0.6.3.2.glibc2.15-x86_64.AppImage --appimage-extract-and-run -d
2022-01-23 00:19:42,606 - WARNING - Using default logger configuration
Running as a daemon. Send TERM signal to end.
user@box:~$ sudo netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nameI was attempting to move to an AppImage to prevent having to install Python 2 and Qt4.
You don't need Qt4 for the daemon.
You don't need Qt4 for the daemon
Although true, the issue still exists with using the appimage with --appimage-extract-and-run -d
I misspoke, BitChan doesn't install Qt4, only Python 2, as a dependency for Bitmessage.
You don't need Qt4 for the daemon
Although true, the issue still exists with using the appimage with --appimage-extract-and-run -d
I misspoke, BitChan doesn't install Qt4, only Python 2, as a dependency for Bitmessage.
The appimage was designed for desktop. I'll repeat what @PeterSurda wrote: running appimage inside of a docker container is a bit overkill, use official Dockerfile. The --appimage-extract-and-run is a workaround for testing environments.
running appimage inside of a docker container is a bit overkill, use official Dockerfile
Even outside docker, the issue persists, as demonstrated in #1924 (comment)
It appears setting the environment variable NO_CLEANUP when also setting APPIMAGE_EXTRACT_AND_RUN (--appimage-extract-and-run), solves the issue:
user@box:~$ export NO_CLEANUP=1
user@box:~$ ./PyBitmessage-0.6.3.2.glibc2.15-x86_64.AppImage --appimage-extract-and-run -d
2022-01-23 11:51:26,844 - WARNING - Using default logger configuration
Running as a daemon. Send TERM signal to end.
user@box:~$ sudo netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8444 0.0.0.0:* LISTEN 301474/././/bin/pyt
tcp 0 0 0.0.0.0:8445 0.0.0.0:* LISTEN 301474/././/bin/pyt
udp 0 0 0.0.0.0:8444 0.0.0.0:* 301474/././/bin/pyt