mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 08:26:00 +02:00
[GH-ISSUE #191] Docker not starting with v1.18.1 on arm64 #151
Labels
No labels
ai-generated
android-app
android-app
android-app
🪲 bug
build
build
dependencies
docs
enhancement
enhancement
🔥 HOT
in-progress 🏃
ios
prio:low
prio:low
pull-request
question
🔒 security
server
server
unified-push
web-app
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy#151
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @iexos on GitHub (Mar 29, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/191
I am trying to run ntfy on docker on a Raspberry 4. Executing
stops after a few seconds without any output, and return code
132. (same if explicitly using the arm64-tagged image)Running on
Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-1056-raspi aarch64)@binwiederhier commented on GitHub (Mar 29, 2022):
There have been issues with arm docker images in the past (search the GitHub issues). I don't have a raspberry pi so it's hard for me to test.
Can you try older image versions?
@binwiederhier commented on GitHub (Mar 29, 2022):
I did a quick check on AWS, with the EC2 Ubuntu 20.04 image on amd64/aarch64 and it worked fine....
@iexos commented on GitHub (Mar 30, 2022):
1.18.0 works, seems to be a recent regression
@binwiederhier commented on GitHub (Mar 30, 2022):
I'm sorry but I can't help unless I can reproduce it or at least have some error message I can Google.
You could try the binary outside of docker and see if that makes a difference, and/or use
straceto show all the system calls it's making, and where it is dying.Those are my only ideas right now.
@iexos commented on GitHub (Mar 30, 2022):
I made straces of both version to compare
strace-ntfy-v1.18.0.log
strace-ntfy-v1.18.1.log
@binwiederhier commented on GitHub (Mar 30, 2022):
I think you probably need to strace the binary and not the docker run command. The 132 is definitely from the Docker binary, but my guess is that that's just a generic exit code when the binary dies. Either download the tarball with the correct binary and run that, or extract it from the docker (see https://github.com/binwiederhier/ntfy/issues/113#issuecomment-1034338993), or exec into the docker and strace in there.
@binwiederhier commented on GitHub (Mar 30, 2022):
You may also want to join the Discord (https://discord.com/invite/cT7ECsZj9w), maybe there are others with a Pi4 that can troubleshoot with you
@iexos commented on GitHub (Mar 30, 2022):
Actually, it is the
ntfybinary returning 132:(there is no strace inside this image)
I can take a look later, if I find out more. Thank you for your quick responses :)
@binwiederhier commented on GitHub (Mar 30, 2022):
This typically only happens if you pick the wrong architecture. You're sure that this is arm64 and not armv7?
I am sorry I can't help more. I gotta get a Pi ;-)
@iexos commented on GitHub (Mar 30, 2022):
This is getting more and more confusing... I extracted both binaries from the docker image, and suddenly v1.18.1 worked and v1.18.0 had illegal instructions. But only once, retrying restored the normal order... I attached the log of what I did as I would not believe myself without it.
@iexos commented on GitHub (Mar 30, 2022):
Also, strace:
@binwiederhier commented on GitHub (Mar 30, 2022):
The is exactly the behavior I have been seeing in #113 (scroll through that ticket a little). It's random almost. I assumed it was because of the
qemu-system-aarch64emulator, but I'm beginning to think it's not.There's one thing we can try: I can build you a binary that isn't compressed with
upx. Let me do that real quick.@binwiederhier commented on GitHub (Mar 30, 2022):
Re-built v1.18.1 without any changes (17M)
Built v1.18.1 WITHOUT
upxpacking (31M)Please do try BOTH of them to see if this is an environmental issue.
@binwiederhier commented on GitHub (Mar 30, 2022):
Also, run each of them many times. In my previous tests it worked sometimes, but not always.
@iexos commented on GitHub (Mar 30, 2022):
No crashes without compression, ~1% crashes with. And a random different crash for good measure. I leave the interpretation to you :)
@binwiederhier commented on GitHub (Mar 30, 2022):
That's amazing and sad at the same time. I'll remove the upx step from the ARM builds then.
@binwiederhier commented on GitHub (Mar 30, 2022):
Try the latest image, v1.19.0.
@iexos commented on GitHub (Mar 30, 2022):
Yepp, that seems to solve it. Im still a bit puzzled whats really happening here, but I guess it doesn't have too much to do with ntfy anyway. Thank you for your effort!
@binwiederhier commented on GitHub (Mar 30, 2022):
The ntfy binary is quite large because it includes the videos and images from the docs, so I use
upx, a binary packer, to compress the binary after it is built. And apparently upx has a bug that makes things crash. That's all I know. So now the binary or ARM is double the size, but it doesn't crash.