AppImage with --appimage-extract-and-run doesn't open ports about pybitmessage HOT 9 CLOSED

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.

from pybitmessage.

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.

from pybitmessage.

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?

from pybitmessage.

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 name

from pybitmessage.

I was attempting to move to an AppImage to prevent having to install Python 2 and Qt4.

You don't need Qt4 for the daemon.

from pybitmessage.

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.

from pybitmessage.

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.

from pybitmessage.

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)

from pybitmessage.

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 

from pybitmessage.