Comments (113)
Did a bit more digging - after my server ran for 40hours straight, no issue hosting up to 3 players at different times. Until silently crashing again at 40 hours, when no one was logged in. Since then it typically fails after 15-45min.
I went into the directory of the non-responsive PID ( /proc/$[PID] ) to do some investigation. I found the following:
Using cat /proc/$[PID]/wchan it returns: futex_wait_queue
Using Sudo cat /proc/$[PID]/syscall it returns something along the lines of:
98 0x150034780 0x80 0x153 0x10080e018 0x0 0x0 0x7fdcdc9a80 0x7facba3c28
This does not change, while the program is stuck.
it's always 98, and always 0x80 for third variable and also always has '0x10080e018 0x0 0x0'
Found within /usr/arm-linux-gnueabihf/include/asm-generic that 98 corresponds to:
#define __NR_futex 98
__SC_3264(__NR_futex, sys_futex_time32, sys_futex)
#endif
Using Sudo cat /proc/$[PID]/stack it always returns the following once the program is stuck:
[<0>] futex_wait_queue+0x78/0xac
[<0>] futex_wait+0x100/0x1c0
[<0>] do_futex+0xec/0x194
[<0>] __arm64_sys_futex+0x84/0x19c
[<0>] invoke_syscall+0x50/0x120
[<0>] el0_svc_common.constprop.0+0x68/0x124
[<0>] do_el0_svc+0x34/0xd0
[<0>] el0_svc+0x30/0x94
[<0>] el0t_64_sync_handler+0xf4/0x120
[<0>] el0t_64_sync+0x18c/0x190
This is all a bit over my head - but hoping this may help determine whether this is box64 related or not..
from box64.
@ptitSeb I already ran it using BOX64_DYNAREX_STRONGMEM=1
. Inspecting the logs with and without STRONGMEM
, I figured out box64 loads libmono which automatically toggles BIGBLOCK=0
and STRONGMEM=1
. Inspecting the folder, it also becomes apparent that mono is involved in the sporadic crash, as there are mono memory dumps created when the server silently crashes (the process still runs, but it doesn't provide any of the expected functions).
from box64.
Hi, author of the guide in OP here.
Thank you all looking into this. :)
I've not had much time to look into this myself and I also brought down my original Ampere instance in OCI.
A month ago I decided to spin up an instance for Terraria and this week I repurposed it for Valheim again to try to help out figuring out this issue.
The instance was running the latest version of Valheim Valheim l-0.217.38 (network version 20)
using Box64 v0.2.6.
No changes were done to environment variables used by Box64 or box64rc.
There were a couple of packages that were needed for Terraria specifically but unfortunately I did not manage to note down the exact ones prior to tearing it down to redo the install (one I do remember on top of my head were libcurl3-gnutls).
I'm in the process of spinning up a new OCI instance using the same specs and will do a clean install of Valheim to narrow down the exact packages.
Edit: I forgot to add that the Valheim server was running over night with no signs of issues (total runtime was about 20 hours prior to teardown).
Edit2: Instance is up and has been running for about 3 hours, no additional steps have been done other than running the installation script from my guide.
I will be letting the server run for a while, connect and play a bit over the weekend then monitor the logs over time to look for abnormalities.
Gist containing details about the server packages etc can be found here and will be updated over time https://gist.github.com/husjon/a94b6760e036e83d0b67a04e3916033d
Update 1: The server usually logs the amount of connections every 10 minutes.
ala: 02/09/2024 22:15:15: Connections 0 ZDOS:30349 sent:0 recv:0
After about 4 hours (18:41 - 22:40UTC) the server has deadlocked.
having to send SIGILL to get it to stop.
This does at the very least give me a baseline to work from.
Update 2: After restarting from the last run and letting it run over night the server ran for just over an hour and deadlocked with no players online.
Update 3: It seem like the packages I mentioned was a false report, I must have used them for something else. I installed the Terraria Server and it started without adding more packages than were already installed, in any case I will start looking at using box64rc to see how the Valheim server behaves.
from box64.
Hi All,
We have two servers running on a Raspberry Pi 5. They've been up for around 60 hours, and 3 players, with this config (and still going strong):
[valheim_server.x86_64]
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE =0
BOX64_DYNAREC_BIGBLOCK=3
EDIT:
The server run for around 100 hours without any problem, and it has been downgraded to a Raspberry Pi 4, that has been running for 10 hours without an issue.
from box64.
If it's a random issue, you can try to start the server with
BOX64_DYNAREC_STRONGMEM=1
(or play with~/.box64rc
if you know it), that might be a needed params.To clarify, should I stay on a more recent built of box64, or revert to 0.2.4 before trying this flag?
Stay on current, it would be easier for me. Als, if it just work with BOX64_DYNARC_STRONGMEM=1
that means that would be the solution! The parameter could go in a config file so it's automaticaly applied.
Also, I would like to provide logs, but they are still huge with BOX64_LOG=2 BOX64_TRACE_FILE=valheim_arm_crash.txt
Is there any way to make them smaller? Thanks again for the help
You can use BOX64_ROLLING_LOG=1
instead, that would just show the last 10 function call before the crash. But if the issue is a multi-thread isseu, those logs will be hardly usefull anyway, as each crash would show something different...
from box64.
Make sure you are using latest version box64 also. Or at least the same version across those various tests.
from box64.
Just to chime in: I was using the guide of husjon to run the server on an OCI Ampere instance.
After updating Valheim, the server hang up silently too - it typically ran only for about 5-10mins. Probably until first world safe.
I'm so glad I found this thread. Using
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE=0
it runs now stable for over 20hrs.
from box64.
For context on my setup, I'm running OCI Ampere with the full specs (4 cores, 24gb ram) on the latest box64 0.2.7
Running the physical machine localy: 128Cores and 96GB of RAM :) That's a gorgeous machine!!!
from box64.
Again I've been too busy with work etc so completely forgot about the Valheim server.
However, today I hopped onto my OCI instance and checked the logs and found that it had crashed yesterday after running for 2.5 weeks (since the restart it has now run for just over a day).
This time systemd was able to recover from it since the executable exited.
Not sure if increasing STRONGMEM could help.
The crash seem to be Mono related from what I can see from the systemd logs.
Unfortunately the box logs I have enabled logs to ~/valheim.box64.log
hence it was overwritten after restarting so I can't provide anything else.
Mar 07 13:09:15 game-server valheim_server.x86_64[918273]: Unloading 0 Unused Serialized files (Serialized files now loaded: 0)
Mar 07 13:09:16 game-server valheim_server.x86_64[918273]: Unloading 0 unused Assets to reduce memory usage. Loaded Objects now: 1727374.
Mar 07 13:09:16 game-server valheim_server.x86_64[918273]: Total: 1664.870040 ms (FindLiveObjects: 689.411280 ms CreateObjectMapping: 88.888240 ms MarkObjects: 876.653400 ms DeleteObjects: 9.914800 ms)
Mar 07 13:19:16 game-server valheim_server.x86_64[918273]: 03/07/2024 13:19:16: Connections 0 ZDOS:51670 sent:0 recv:0
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Native Crash Reporting
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Got a SIGSEGV while executing native code. This usually indicates
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: a fatal error in the mono runtime or one of the native libraries
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: used by your application.
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Native stacktrace:
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: 0x7fff031151f2 - /home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: 0x7fff030bdecd - /home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_unity_backtrace_from_context
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: 0x7fff03110bd1 - /home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: 0x30333 - Unknown
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Telemetry Dumper:
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: =================================================================
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Pkilling 0x281473320415264x from 0x281471878819808x
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Pkilling 0x281473164767200x from 0x281471878819808x
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Pkilling 0x281472702459872x from 0x281471878819808x
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Pkilling 0x281473256583136x from 0x281471878819808x
Mar 07 13:27:05 game-server valheim_server.x86_64[1702823]: Could not exec mono-hang-watchdog, expected on path '/home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/etc/../bin/mono-hang-watchdog' (errno 2)
Mar 07 13:27:05 game-server valheim_server.x86_64[918273]: Entering thread summarizer pause from 0x281471878819808x
Mar 07 13:27:05 game-server systemd[881]: valheim_server.service: Main process exited, code=killed, status=6/ABRT
Mar 07 13:27:05 game-server systemd[881]: valheim_server.service: Failed with result 'signal'.
Mar 07 13:27:05 game-server systemd[881]: valheim_server.service: Consumed 1w 7h 2min 3.252s CPU time.
Mar 07 13:27:10 game-server systemd[881]: valheim_server.service: Scheduled restart job, restart counter is at 2.
Mar 07 13:27:10 game-server systemd[881]: Stopped Valheim Dedicated Server.
Mar 07 13:27:10 game-server systemd[881]: valheim_server.service: Consumed 1w 7h 2min 3.252s CPU time.
Mar 07 13:27:10 game-server systemd[881]: Started Valheim Dedicated Server.
Mar 07 13:27:10 game-server valheim_server.x86_64[1702826]: Applying BOX64_LOG=1
Mar 07 13:27:10 game-server valheim_server.x86_64[1702826]: Applying BOX64_DYNAREC_BIGBLOCK=0
Mar 07 13:27:10 game-server valheim_server.x86_64[1702826]: Applying BOX64_DYNAREC_STRONGMEM=2
Mar 07 13:27:10 game-server valheim_server.x86_64[1702826]: Applying BOX64_DYNAREC_BLEEDING_EDGE=0
Mar 07 13:27:10 game-server valheim_server.x86_64[1702826]: Applying BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
Mar 07 13:27:11 game-server valheim_server.x86_64[1702826]: [UnityMemory] Configuration Parameters - Can be set up in boot.config
Update 2024-03-22: After the restart (after the mentioned crash) the server is still running fine (Box64 with Dynarec v0.2.7 ea86b0e built on Feb 17 2024 12:21:23).
I've also made the changes available in my guide for Valheim pinning it to use box64 v0.2.6 (since it is the latest release) with the previously mentioned configuration.
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
from box64.
Thanks for those analysis, that some interesting stats.
It seems this is some multitasking issues. My feeling is that
BOX4_DYNAREC_STRONGMEM
is the main parameter to tweek (values from 0 to 3, 0 is default). ButBOX64_DYNAREC_BIGBLOCK
might have some effect too (values from 0 to 3, 1 is default). If MonoBleedingEdge is loaded, it will override those settings, so you need to useBOX64_DYNAREC_BLEEDING_EDGE =0
to disable this lib detection have have full control on the settings. Use the~/.box64rc
or/etc/box64.box64rc
file with the[valheim_server.x86_64]
section has mentionned earlier for easy tweaking.
Similar to @ebarrragn I set the following:
Environment=BOX64_DYNAREC_STRONGMEM=3
Environment=BOX64_DYNAREC_BIGBLOCK=2
Environment=BOX64_DYNAREC_BLEEDING_EDGE=0
Servers been MUCH more stable and running for long hours on a pi4 4gb. ran for 43 hours the other day which it has never done before for me. I believe modifying the settings may be the solution. I will have to try with bigblock = 3.
from box64.
Just wanted to follow up that it's been much more stable running with:
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE=0
Though we're still getting a crash after several hours. Frequency seems to be around ~3-5hrs
from box64.
@husjon Ok perfect, added the variables to .box64rc
and it's showing up when I start the server now. Thanks!
from box64.
can confirm, applying
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
using box64 v0.2.6 on OCI instance (with all A1 resources), my server is running uninterrupted for the last 24h (-nocrossplay)
@ptitSeb @husjon:
I realy appreciate your time investment to help us peasants keep our server running. If you like to dig deeper into troubleshooting this issue, I would like to support by using diffrent parameters or hopping on your server for stresstesting
from box64.
can confirm, applying [valheim_server.x86_64] BOX64_DYNAREC_BLEEDING_EDGE=0 BOX64_DYNAREC_STRONGMEM=3 using box64 v0.2.6 on OCI instance (with all A1 resources), my server is running uninterrupted for the last 24h (-nocrossplay)
@ptitSeb @husjon: I realy appreciate your time investment to help us peasants keep our server running. If you like to dig deeper into troubleshooting this issue, I would like to support by using diffrent parameters or hopping on your server for stresstesting
Well, since box64 v0.2.6, I have redone some work around STRONGMEM, so you can update to latest box and try to see if it sttill work at strongmem 3 and also try to lower to 2.
Not sure how to measure performances also on the server?
from box64.
Mmm, ok. I'll have a look, at why the server doesn't run anymore.
from box64.
(removed the image, not sure it's wise to let all those hash stuff there)
That's the server running right?
from box64.
@nitroinferno environment variables set directly on the executable should be taking precedence over any configuration files (that is at least that's what normal).
I think the reason why you didn't see any output about them being set is because you did not have BOX64_LOG
set.
from box64.
Ah that makes sense thanks @husjon!
Another interesting thing is when the instance autosaves I get a bunch of sigpwr and sigxcpu signals - also sometimes it throws segfaults when running (this current iteration of the program running isn't throwing segfaults though). I am using v0.2.7 57ca9df built on Jan 18 2024. I'm a novice (just started using linux in Dec.) and not even sure on how to update the box64 version and whether I need to run through cmake stuff again or what.
Another interesting bit is my program creates 44 threads (believe the ampere creates 36?) And mine consumes a LOT of cpu time/usage (see end code block).
Guessing the following may be because weakness od using rpi4 4gb?
nitro@raspberrypi:~ $ strace -p $(pgrep valheim) -e 'status=!all'
strace: Process 86659 attached
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGXCPU {si_signo=SIGXCPU, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=86659, si_uid=1000} ---
Lot of cpu usage compared to actual runtime
nitro@raspberrypi:~/box64 $ systemctl status valheim
● valheim.service - Valheim Dedicated Server
Loaded: loaded (/etc/systemd/system/valheim.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-02-16 20:15:25 EST; 16h ago
Main PID: 86659 (valheim_server.)
Tasks: 44 (limit: 3919)
CPU: 1d 10h 43min 45.438s
CGroup: /system.slice/valheim.service
└─86659 /home/nitro/valheim_server/valheim_server.x86_64 -nographics -batchmode >
from box64.
It sounds like a potential solution for now would be to run box64 on v0.2.6 since that appears to be working.
from box64.
@Pohtaytoh for OCI Ampere I agree that v0.2.6 should be fine as long as the configuration is set correctly.
Referencing my comment #1182 (comment) and #1182 (comment), I will add a comment in my guides comment section soon for more people to try out this version and if people are satisfied with it I will update the guide and installer. :)
from box64.
Ok, I reverted to box64 v0.2.6 on my server and it seems much more stable so far. Will report back in a day to see if we get the same results you did @husjon
Update1: It's been just about 8hrs since I reverted to 0.2.6, and this has been the longest my server has been up without crashing since the Valheim update. I've been logging in every hour or so and had a friend log in with me at one point. Very stable so far.
Update2: Confirmed this morning (~19hrs since revert) that the server is still up. This is the longest we've been able to keep it running so far, and I believe this was the missing piece to replicating @husjon's results.
Results: Running on oracle cloud's Ampere A1 instance, VM.Standard.A1.Flex
4 cores, 24gb ram on box64 v0.2.6
with the following environmental variables:
~/.box64rc
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
#BOX64_DYNAREC_BIGBLOCK=3
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
from box64.
Also, note that the new box64 has a secret strongmem=4 parameter, that should be equivalent to the strongmem=3 of v0.2.6
from box64.
My OCI instance is now running the server for 11 hours straight without crashing. That is the longest it was able to run since November last year. On a side note, I noticed the CPU usage for the process increased considerably, is that expected with strongmem = 4?
Yes, the the higher the strongmem parameter, the higher the cpu usage for the same workload. That's excpected.
from box64.
Just to chime in as well. Going on 4 days, and server is still going strong since we reverted to 0.2.6.
from box64.
My server has been running on my raspberry pi 4 now that only has 4GB of RAM for over a week with no crashes! Me and my friend hop on and play for hours at a time no problems. Still using the version I mentioned before: v0.2.7 57ca9df
Valheim developers minimum recommended RAM is 8GB. So 20 is probably a little overkill 10 GB should be fine.
from box64.
I have not had much time to look into it myself but since my last update (#1182 (comment)) the server was running for just over a month (using v0.2.7 ea86b0e).
I just rebuilt box64 with the commit (v0.2.7 eda857c) mentioned by @tiagojofran and restarted the server, no issues so far, but I'll check in on it a bit later today.
from box64.
Hi, @husjon.
Yes, I updated valheim server to version 217.46 and the issue still persists.
It's really strange, only valheim is giving me a hard time, other game servers are running just fine on the same system through box64, and I didn't change its settings from the previous box64 version.
If I roll back to v. 0.2.7 ed2697d, the problem is gone.
from box64.
Thank you for testing it, @husjon, I think we can now assume that the issue is probably only affecting my system.
I just tried to run the server with the same settings as yours, and unfortunately it could only run for about 2 hours until it finally crashed again.
I really have no idea what is happening to my system, so I think I have no alternative other than rolling back to the box64 version that still works for me. Thanks again for your help.
from box64.
Oh wow 2 weeks uptime with no faults! With this I think ill roll my box64 forward to v0.2.7 eda857c. I'll Give a test run and report back.
Apparently I've read pi5 has its own share of issues as well outside pi4.
What's interesting is when I was using build: v0.2.7 57ca9df it ran best with BIGBLOCK=3, however v0.2.6 cannot use bigblock=3 at all. It will not even get through start sequence.
There were not a lot of crashes with v0.2.7 57ca9df, however it would instead silently lock up about the same amount: 12-24hr intervals.
from box64.
Pi 4b rev1.2 4gb:
Mine has been up 3 days this current iteration but typically it faults near this or 2 day mark.
nitro@raspberrypi:~/box64 $ cat /proc/cpuinfo
processor : 0
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 1
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 2
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Revision : c03112
Serial : 100000008f6a4932
Model : Raspberry Pi 4 Model B Rev 1.2
from box64.
Ah yes this is a common occurrence I've come across with the rpi. I've chalked it up to the limited resources it has available. I created a service to detect and force a restart. Uses: [ps -o state -p $PID --no-headers] to get state, if its been S constantly for 60s its deadlocked. It only happens occasionally on v0.2.6 - its usually ABRT or TRAP signal kills (which i believe are the mono crashes). What's interesting is I noticed the deadlock was more prevelant on later builds - whereas the mono crashes were a lot less.
Somehow setting bigblock=3 significantly reduced the number of deadlocks in later builds - I have no idea why. I'll spin up a da857c later once I get a chance.
from box64.
So far I've had the server running for about 36 hours with the problematic version mentioned above. (eda857c)
Box64 with Dynarec v0.2.7 eda857cb built on May 2 2024 21:21:30
I've been using the following settings:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=2
BOX64_LOG=1
BOX64_TRACE_FILE=/home/pi/valheim.box64.log
@spwly it depends on how you installed box64, but assuming you used git, you'd need to check out the version / commit you're interested in, then do the cmake / make / make install procedure.
For example:
cd ~/box64/build
git fetch
git checkout <TAG / VERSION HERE> # (specific version: "v0.2.6" or commit "eda857cb")
cmake .. -DRPI4ARM64=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j"2"
sudo make install
from box64.
Many thanks @husjon - I got my version to eda857c . It didn't seem to affect my performance either, so I determined my issue must be elsewhere. Turns out, I hadn't been installing the box64rc file, and was only making changes to the file within /system. Properly installed with your settings, it has been up and running for over two hours now. I will let it run until I get a crash and report back with my total uptime.
Update: Must have jinxed it, crapped out right at 3 hours. Progress is progress though
from box64.
Just to make sure that it is picking up the environment variables (if you used the exact ones I mentioned), you should see the following lines shortly after starting it (only if LOG is set to 1 or higher).
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_LOG=1 May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_BIGBLOCK=0 May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_STRONGMEM=2 May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_BLEEDING_EDGE=0 May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_TRACE_FILE=/home/pi/valheim.box64.log
Thanks for mentioning this, because this was definitely not showing up for me. Apparently my box64rc settings were never being read. My issue was the file in the home directory, box64.box64rc needed to be renamed to just ".box64rc"!
With those parameters finally successfully set, I booted up the server last night after updating (new biome is out!) and played for a few hours with two other players. Everything ran smoothly and the server is still running 18 hours later.
I am running everything off the internal SD card, so if I get any more performance issues, I will try running off an SSD and see if it has any effect. I'm also curious if running the pi headless would speed things up.
from box64.
Valheim server still works using Box64 v0.2.4 on my end (RPI4 4GB, Ubuntu 64bit), but fails to start using v0.2.6.
However, starting with v0.2.4 leads to a server crash after an arbitrary amount of time (leaving behind mono_crash memory dumps)
from box64.
@sea212 did you try with current version also? Can you bisect the issue if it's still broken?
from box64.
@ptitSeb I'll provide more information shortly.
from box64.
When tried to bisect I realized that I can't reliably reproduce the error that the server hangs on launch. Sometimes it does, most of the times it seems to work.
from box64.
If it's a random issue, you can try to start the server with BOX64_DYNAREC_STRONGMEM=1
(or play with ~/.box64rc
if you know it), that might be a needed params.
from box64.
If it's a random issue, you can try to start the server with
BOX64_DYNAREC_STRONGMEM=1
(or play with~/.box64rc
if you know it), that might be a needed params.
To clarify, should I stay on a more recent built of box64, or revert to 0.2.4 before trying this flag?
Also, I would like to provide logs, but they are still huge with
BOX64_LOG=2 BOX64_TRACE_FILE=valheim_arm_crash.txt
Is there any way to make them smaller? Thanks again for the help
from box64.
@ptitSeb Ok,
I recompiled to make sure I am on the latest version
box64 --version
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL SHA1 SHA2 PageSize:4096 Running on Neoverse-N1 with 4 Cores
Params database has 48 entries
Params database has 48 entries
Box64 with Dynarec v0.2.7 41bfd757 built on Jan 7 2024 20:31:39
I ran this below and was able to generate a more interesting log
BOX64_DYNARC_STRONGMEM=1 BOX64_ROLLING_LOG=1 BOX64_TRACE_FILE=valheim_arm_crash.txt /home/ubuntu/valheim_server/valheim_server.x86_64
\ -nographics -batchmode -port 2456 -public 1 -name serverName -password sometemporarydummypassword
\ -savedir /home/ubuntu/valheim_data
In particular
Warning: Global Symbol _ZTH15gDeferredAction not found, cannot apply R_X86_64_GLOB_DAT @0x7fff01d3d660 ((nil)) in /home/ubuntu/valheim_server/UnityPlayer.so
Error loading needed lib libpulse-mainloop-glib.so.0
Error loading one of needed lib
Error initializing needed lib /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libparty.so
Which is odd, previously libpulse-mainloop was only needed for crossplay, so maybe the default behavior is now crossplay on?
from box64.
I'm on an RPI 5 running Ubuntu Server 23.10, getting the same issue as those above - silent crashing after an arbitrary period of time.
I'm running
Dynarec will try to emulate a strong memory model with limited performance loss
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL SHA1 SHA2 PageSize:4096 Running on Cortex-A76 with 4 Cores
Params database has 48 entries
Box64 with Dynarec v0.2.7 328d5c62 built on Jan 11 2024 19:17:20
To note, I'm seeing occasional Error loading one of needed lib
errors, such as:
Error loading needed lib libparty.so
Warning: Cannot dlopen("libparty.so"/0x71ab21f0, 101)
Using emulated ./linux64/steamclient.so
Redirecting overridden malloc from symtab function for ./linux64/steamclient.so
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0c233fb8 (0x32a296)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0c233fc0 (0x32a2a6)
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0c233fc8 (0x32a2b6)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0c233fd0 (0x32a2c6)
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Using native(wrapped) crashhandler.so
CAppInfoCacheReadFromDiskThread took 1 milliseconds to initialize
Error loading needed lib steamservice.so
Warning: Cannot dlopen("steamservice.so"/0xffff786ba8b0, 2)
dlmopen steamservice.so failed: Cannot dlopen("steamservice.so"/0xffff786ba8b0, 2)
Setting breakpad minidump AppID = 892970
SteamInternal_SetMinidumpSteamID: Caching Steam ID: 76561197960265728 [API loaded no]
Error loading needed lib libsteam.so
Warning: Cannot dlopen("libsteam.so"/0x7fff07038ad9, 2)
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
Let me know if there's anything else I can provide.
from box64.
In addition to the above, I took a log of my last run of the game using the following shell script:
#!/bin/bash
export templdpath=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./linux64:$LD_LIBRARY_PATH
export SteamAppId=892970
export BOX64_SHOWBT=1
export BOX64_LOG=1
export BOX64_TRACE_FILE=log.txt
export BOX64_DYNAREC_STRONGMEM=1
echo "Starting server PRESS CTRL-C to exit"
# Tip: Make a local copy of this script to avoid it being overwritten by steam.
# NOTE: Minimum password length is 5 characters & Password cant be in the server name.
# NOTE: You need to make sure the ports 2456-2458 is being forwarded to your server through your local router & firewall.
./valheim_server.x86_64 \
-name "something" \
-port 2456 \
-world "something" \
-password "secret" \
-nographics \
-batchmode \
-public 0 \
export LD_LIBRARY_PATH=$templdpath
Pardon my ignorance, but it's curious to see so many errors about libpulse-mainloop-glib.so.0
- If I run sudo apt install libpulse-mainloop-glib0
I'm apparently on the newest version. party.so
straight up doesn't exist, but libparty.so
does in /valheim_server_Data/Plugins
. steamservice.so
doesn't appear to exist on my system.
from box64.
I am having a similar issue. I do not have BOX64_DYNARC_STRONGMEM set to 1.
Details from box64 --version:
Dynarec for ARM64, with extension: ASIMD CRC32 PageSize:4096 Running on Cortex-A72 with 4 Cores
Params database has 49 entries
Box64 with Dynarec v0.2.7 57ca9df built on Jan 18 2024 22:03:56
Whats interesting is, sometimes the Valheim service will run fine for a bit (up to 8 hrs it ran once!), sometimes it will only live for roughly 5 minutes before silent failure.
Recently though, the Valheim service has been silently failing typically after an hour, usually sooner in recent days.. can't get it to run up to anywhere near 8 hours again...
If it would help for me to run and trace logs I can do so if it helps resolve this sooner. I am a novice at linux and bash however but I think I could handle running a similar script to that mentioned above.
from box64.
@nitroinferno what if you run with BOX64_DYNAREC_STRONGMEM=1
? Does it make the server more stable?
from box64.
@ptitSeb How do I run the valheim service with BOX64_DYNAREC_STRONGMEM=1 from terminal? For example I run the server exec from valheim.service, and typically do 'systemctl start valheim' right in the terminal.
from box64.
@ptitSeb How do I run the valheim service with BOX64_DYNAREC_STRONGMEM=1 from terminal? For example I run the server exec from valheim.service, and typically do 'systemctl start valheim' right in the terminal.
The simpler would be to use either /etc/box64.box64rc
or if the account used for the service has a home, create a .box64rc
file in that home and put inside:
[valheim_server.x86_64]
BOX64_DYNAREC_STRONGMEM=1
And the parameter will automatically picked up.
from box64.
@ptitSeb How do I run the valheim service with BOX64_DYNAREC_STRONGMEM=1 from terminal? For example I run the server exec from valheim.service, and typically do 'systemctl start valheim' right in the terminal.
The simpler would be to use either
/etc/box64.box64rc
or if the account used for the service has a home, create a.box64rc
file in that home and put inside:[valheim_server.x86_64] BOX64_DYNAREC_STRONGMEM=1And the parameter will automatically picked up.
Thank you, I set it under the /etc/box64.box64rc, since the service runs from /etc/ directory. Seems the program is staying alive stable now (could also be luck of the draw). However, its been running for just a bit over 2 hours, which it hasn't done for awhile. I will continue to monitor it. Its been quite some time that it ran for this long without the silent failure.
To sea212's point, I do have mono_crash.mem files within ~/home//valheim_server/ directory. There are 7 files to be specific. Believe these are from the silent failures earlier in the day, I did not reboot since modifying the box64.box64rc
Update: Seems it was luck of the draw it ran 2 hours. After restarting it didn't stay online for longer than 5minutes, then subsequent restarts wouldn't last beyond 15m.
from box64.
I believe there may be 2 issues at hand. The crashes on initialization / startup sometimes generate the mono_crash.mem files (these crashes are RARE - at least in my case). I overclocked by rpi4 to 2GHz and it stopped any and all crashing on startup / initialization. I am suspecting they may be somehow tied to the lower end clock rate of the CPU? (I have no gauge whether this makes logical sense or not)
I created a service which monitors to see if the primary .x86_64 PID has become stuck in 'Sleeping' status as seen in htop. This is an easy work around to the sporadic failed starts.
My main issue is how to diagnose or provide useful info on when the main process gets stuck in 'sleeping' state. I tried running with BOX64_LOG=1 but I don't think it provided any useful info; it pretty much looked similar to #1182 (comment). I Tried running BOX64_LOG=2 and 3, and it both generated a log file that was enormous and it couldn't get through a startup / initialization routine. I believe the RPI4 isn't powerful enough to handle all this logging and initialization simultaneously.
From strace -c I get a lot of errors reported for futex, restart_syscall, and read.
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
52.30 0.062819 112 557 59 futex
23.66 0.028420 1291 22 clock_nanosleep
14.65 0.017595 2199 8 4 restart_syscall
8.88 0.010666 2133 5 epoll_pwait
0.26 0.000316 26 12 clock_gettime
0.16 0.000193 193 1 sendto
0.04 0.000053 13 4 4 read
0.03 0.000037 37 1 recvfrom
0.00 0.000003 1 2 pselect6
0.00 0.000001 0 4 ppoll
------ ----------- ----------- --------- --------- ----------------
100.00 0.120103 194 616 67 total
I suspect the issue is a deadlock or resource contention issue causing the sporadic silent failures, where the main process cannot be returned to 'running' status after going to 'sleep'. Is there any BOX64 settings I can tweak to avoid this, or methods I can use to generate more useful log data?
note: I tried using gbd to get useful trace info logs both when running, and stuck in sleeping state. Not sure how useful these are I will attach one of each to this post.
stack_traceRun.txt
stack_tracescrash.txt
from box64.
Thanks for those analysis, that some interesting stats.
It seems this is some multitasking issues. My feeling is that BOX4_DYNAREC_STRONGMEM
is the main parameter to tweek (values from 0 to 3, 0 is default). But BOX64_DYNAREC_BIGBLOCK
might have some effect too (values from 0 to 3, 1 is default).
If MonoBleedingEdge is loaded, it will override those settings, so you need to use BOX64_DYNAREC_BLEEDING_EDGE =0
to disable this lib detection have have full control on the settings.
Use the ~/.box64rc
or /etc/box64.box64rc
file with the [valheim_server.x86_64]
section has mentionned earlier for easy tweaking.
from box64.
I've been trying to run the server in OCI on Ampere trying out a variety of environment variables but not getting any positive results, using the following environment variables:
BOX64_LOG=1
BOX64_DYNAREC_BIGBLOCK=3
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
The tracefile is spammed of the following segfaults triggered by FillBlock:
FillBlock at 0x2fdd70 triggered a segfault, canceling
FillBlock triggered a segfault at 0x300000 from 0x35012ef4
FillBlock at 0x2fddbc triggered a segfault, canceling
FillBlock triggered a segfault at 0x300000 from 0x35012ef4
FillBlock at 0x2fddd4 triggered a segfault, canceling
https://gist.github.com/husjon/a94b6760e036e83d0b67a04e3916033d#file-valheim-box64-deadlock-01-log
It then refuses to continue or stop and I have to send SIGILL.
I'll continue to play around with the variables to see if I can get some more info.
Update:
Leaving only the following variables the server starts up normally
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
normal startup log: https://gist.github.com/husjon/a94b6760e036e83d0b67a04e3916033d#file-valheim-box64-normal-log
from box64.
I've been on v0.2.6 for all tests so far, but I'll take a look at building and testing towards latest on main a bit later.
from box64.
After settings BLEEDING_EDGE=0
and STRONGMEM=3
, the server have now been running for just over 20 hours (using Box64 v0.2.6).
I will let the server run for a while longer to see how it behaves.
Update 1: The server has now been running for close to 30 hours and still chugging along, still I feel it might be too early to say for sure so I'll continue to monitor the server.
Currently the server is using Steams multiplayer backend, but I'm curious to see how it would behave if Crossplay was enabled as that would use PlayFabs backend instead (this was a massive PITA when we tried getting it going before), I might spin up a separate instance for testing that at some point.
from box64.
My server is encountering a crash after 5-15mins which subsequently throws a "failed to connect" when trying to reconnect. We end up needing to restart the server to connect successfully only for it to eventually crash again. This was with just 1-2 people to test the variables.
I'm running the suggested variables mentioned above:
BOX64_DYNAREC_BIGBLOCK=3
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE=0
from box64.
My server is encountering a crash after 5-15mins which subsequently throws a "failed to connect" when trying to reconnect. We end up needing to restart the server to connect successfully only for it to eventually crash again. This was with just 1-2 people to test the variables.
I'm running the suggested variables mentioned above:
BOX64_DYNAREC_BIGBLOCK=3 BOX64_DYNAREC_STRONGMEM=3 BOX64_DYNAREC_BLEEDING_EDGE=0
@Pohtaytoh Try setting the bigblock above to =2. Just a shot in the dark but mines been consistently working 40+ hours with it set to that with other settings above, though I'm hosting on a rpi4 without OCI ampere.
from box64.
My server running on my OCI Ampere instance is still running smoothly after 50+ hours.
I haven't had much time to play but I do hop onto it every now and then to explore and generate terrain etc.
● valheim_server.service - Valheim Dedicated Server
Loaded: loaded (/home/ubuntu/.config/systemd/user/valheim_server.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2024-02-10 15:51:57 UTC; 2 days ago
Main PID: 42305 (valheim_server.)
Tasks: 36 (limit: 14216)
Memory: 2.0G
CPU: 22h 5min 10.234s
CGroup: /user.slice/user-1001.slice/[email protected]/app.slice/valheim_server.service
Variables used as mentioned in my previous comment (with Box64 v0.2.6):
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BLEEDING_EDGE=0
BIGBLOCK
is not used.
from box64.
My server on my OCI Ampere instance have now been running for 5 days straight with no issues using the previously mentioned environment variables (see: #1182 (comment)).
What I've not been able to test is how it acts with multiple people being connected but this is very promising for the guide and I will ask a few more people to help with more testing.
from box64.
Just to be on the same page, I added those two variables to /etc/box64.box64rc
is this the case for you all?
from box64.
@Pohtaytoh I used ~/.box64rc
, but /etc/box64.box64rc
also works, however if configuration exists in ~/.box64rc
, it would take precedence.
See https://github.com/ptitSeb/box64/blob/main/docs/USAGE.md#usage for more information
Box64 look for 2 places for rcfile: /etc/box64.box64rc and ~/.box64rc The second takes precedence to the first, on an APP level (that means if an [MYAPP] my appears in both file, only the settings in ~/.box64rc will be applied)
You should see when you start the server that it outputs a couple of lines stating that it applied these variables.
Example:
Feb 10 15:51:57 game-server systemd[881]: Started Valheim Dedicated Server.
Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_LOG=1
Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_DYNAREC_STRONGMEM=3
Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_DYNAREC_BLEEDING_EDGE=0
Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: [UnityMemory] Configuration Parameters - Can be set up in boot.config
from box64.
After checking my logs, the crashes we're experience does seem to stem from the environmental variables not being passed properly when the server starts.
When I try to edit ~/.box64rc
I get an empty doc. Would y'all have guidance on getting the variables set up properly? I'm assuming I'm looking in the correct place, and would just need to create it myself?
from box64.
@Pohtaytoh mine looks like the following:
ubuntu@game-server:~$ cat .box64rc
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
ubuntu@game-server:~$
The log and tracefile is just for good measure in case it should crash.
from box64.
@husjon This is when I get when I run that command:
ubuntu@instance:~$ cat .box64rc
cat: .box64rc: No such file or directory
from box64.
@Pohtaytoh I used cat
to get the content, you need to open it yourself and add the content, then restart the server :)
from box64.
Running with these settings, I was was able to get a couple hours of playtime before it crashed again.
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
Added BOX64_DYNAREC_BIGBLOCK=2
back in, then rebooted the system to see if that performed better:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
BOX64_DYNAREC_BIGBLOCK=2
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
Didn't have time to play, but I left it overnight and when I tried to reconnect this morning I received a "failed to connect" error.
Here's what's in the tracefile:
Rename process to "valheim_server.x86_64"
Using emulated UnityPlayer.so
Using native(wrapped) libm.so.6
Using emulated /lib/x86_64-linux-gnu/libgcc_s.so.1
Using native(wrapped) libpthread.so.0
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libdl.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using native(wrapped) libbsd.so.0
Warning: Global Symbol _ZTH15gDeferredAction not found, cannot apply R_X86_64_GLOB_DAT @0x7fff01d3d660 ((nil)) in UnityPlayer.so
Using emulated /home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so
Using native(wrapped) libz.so.1
Using emulated /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libDiskSpacePlugin.so
Using emulated /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libparty.so
Redirecting overridden malloc from symtab function for /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libparty.so
Using native(wrapped) libatomic.so.1
Using native(wrapped) libpulse.so.0
Using native(wrapped) libpulse-simple.so.0
Using native(wrapped) libpulse-mainloop-glib.so.0
Using emulated /lib/x86_64-linux-gnu/libstdc++.so.6
Warning: Global Symbol _ZN9__gnu_cxx21zoneinfo_dir_overrideEv not found, cannot apply R_X86_64_GLOB_DAT @0x7fff0624e268 ((nil)) in /lib/x86_64-linux-gnu/libstdc++.so.6
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624f060 (0x9c0f6)
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624f6a0 (0x9cd76)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624fb00 (0x9d636)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624fff8 (0x9e026)
Warning: Weak Symbol _ITM_memcpyRnWt not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff062504a8 (0x9e986)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff06250c88 (0x9f946)
Using emulated /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libsteam_api.so
Redirecting overridden malloc from symtab function for /home/ubuntu/valheim_server/valheim_server_Data/Plugins/libsteam_api.so
Using emulated /home/ubuntu/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmono-native.so
Using emulated ./linux64/steamclient.so
Redirecting overridden malloc from symtab function for ./linux64/steamclient.so
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0b233fb8 (0x32a296)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0b233fc0 (0x32a2a6)
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0b233fc8 (0x32a2b6)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0b233fd0 (0x32a2c6)
Using native(wrapped) crashhandler.so
Error loading needed lib steamservice.so
Warning: Cannot dlopen("steamservice.so"/0xffff40199290, 2)
Error loading needed lib libsteam.so
Warning: Cannot dlopen("libsteam.so"/0x7fff07038ad9, 2)
Error loading needed lib libSDL3.so.0
Warning: Cannot dlopen("libSDL3.so.0"/0x7fff0a96150c, 2)
from box64.
@Pohtaytoh you using ampere oci instance or raspberrypi?
from box64.
@nitroinferno it is an Ampere A1 instance, VM.Standard.A1.Flex
from box64.
@Pohtaytoh mine looks like the following:
ubuntu@game-server:~$ cat .box64rc [valheim_server.x86_64] BOX64_DYNAREC_BLEEDING_EDGE=0 BOX64_DYNAREC_STRONGMEM=3 BOX64_LOG=1 BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log ubuntu@game-server:~$The log and tracefile is just for good measure in case it should crash.
Unfortunately for me, applying these settings on my OCI instance could only keep the server alive for a couple hours, about 3 to 5 hours I believe, before silently crashing again. I tried restarting it a couple times, but the result is always the same.
I'm on box64 v0.2.7 c70581a, by the way.
from box64.
@ptitSeb Building from master 5924a8e does result in a binary that isn't even capable to start the server on my RPI 4b (neither with default parameters nor with parameter suggested in this issue). The server just silently crashes during initialization.
from box64.
can confirm, applying [valheim_server.x86_64] BOX64_DYNAREC_BLEEDING_EDGE=0 BOX64_DYNAREC_STRONGMEM=3 using box64 v0.2.6 on OCI instance (with all A1 resources), my server is running uninterrupted for the last 24h (-nocrossplay)
@ptitSeb @husjon: I realy appreciate your time investment to help us peasants keep our server running. If you like to dig deeper into troubleshooting this issue, I would like to support by using diffrent parameters or hopping on your server for stresstestingWell, since box64 v0.2.6, I have redone some work around STRONGMEM, so you can update to latest box and try to see if it sttill work at strongmem 3 and also try to lower to 2. Not sure how to measure performances also on the server?
@ptitSeb good to know.
As for the Valheim OCI setup guide I'm satisfied with pinning box64 to v0.2.6 until further testing has been done towards latest on main.
As for my instance it has now been running a week straight with no issues (v0.2.6).
The instance itself even runs with about half the spec compared to my guide (2 cores and 12GB ram).
I will however try updating box64 to latest on main and play around with the configuration to see how it behaves.
from box64.
With v0.2.7-ea86b0e3
current main, I'm not able to get the server running at all, or more correctly it segfaults (SIGSEGV
) shortly after startup.
I've tried adjusting STRONGMEM and BIGBLOCK with or without BLEEDING_EDGE, but no amount of adjustments makes any difference.
Server startup log with tracefile can be found here
https://gist.github.com/husjon/a94b6760e036e83d0b67a04e3916033d#file-box64-v0-2-7-ea86b0e3-valheim-sigsegv
from box64.
In case you should need more information and/or even direct access I can set something up for you.
from box64.
For context on my setup, I'm running OCI Ampere with the full specs (4 cores, 24gb ram) on the latest box64 0.2.7
Running with the env variables:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
I've also tried it with BOX64_DYNAREC_BIGBLOCK=2
and BOX64_DYNAREC_BIGBLOCK=3
Like others, I consistently crash within 3-5hrs whether there's someone playing or not.
from box64.
I installed the server from Steam, as I have the game on my collection, and started the server on my machine (it's an Ampere ADLink, so the same Neoverse-N1 CPU, but local version, not on AWS).
It seems to launch fine for me.
I notice on your log the lack of libpulse-mainloop-glib.so.0
lib. You might want to install this lib maybe?
from box64.
Yeah that's even with crossplay enabled
from box64.
Well, try to install this lib: sudo apt install libpulse-mainloop-glib0
(not sure why it would sendenly be mandatory, but worth a try)
from box64.
Hm I though I already had it installed, but yeah you're right that was the missing piece.
The server just started up again only having log and tracefile enabled.
I'll monitor it for a while and report back.
Thanks
from box64.
@Pohtaytoh My server is running in exact this environment fine with zero crashes so far. As I think it happens on world save, what is your world size? (Mine is ~19Mb)
from box64.
@Pohtaytoh I used
~/.box64rc
, but/etc/box64.box64rc
also works, however if configuration exists in~/.box64rc
, it would take precedence.See https://github.com/ptitSeb/box64/blob/main/docs/USAGE.md#usage for more information
Box64 look for 2 places for rcfile: /etc/box64.box64rc and ~/.box64rc The second takes precedence to the first, on an APP level (that means if an [MYAPP] my appears in both file, only the settings in ~/.box64rc will be applied)
You should see when you start the server that it outputs a couple of lines stating that it applied these variables. Example:
Feb 10 15:51:57 game-server systemd[881]: Started Valheim Dedicated Server. Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_LOG=1 Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_DYNAREC_STRONGMEM=3 Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_DYNAREC_BLEEDING_EDGE=0 Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: Applying BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log Feb 10 15:51:57 game-server valheim_server.x86_64[42305]: [UnityMemory] Configuration Parameters - Can be set up in boot.config
So something interesting to note here. I set the box64 environment variables in the .service file directly (not in /etc/box64.box64rc or ~/.box64rc). I dont get the log indicating box64 params set as above, on server start. However, my rpi4 with only 4GB can run the server typically 40-70hrs straight now after this change, It could not do this before setting these in the .service. It runs very smoothly with 2 players playing for many hours even!
I set the same params last night in the actual /etc/box64.box64rc file, and it shows in the journalctl log for the service, as quoted above. So I am wondering was box64 getting the right params previously when set directly in the .service file or was it dumb luck it was running well?
Could there be conflicts or issues setting these box64 params both in the .service AND /etc/box64.box64rc?
Valheim.service file Environment parameters:
[Service]
Environment=SteamAppId=892970
Environment=LD_LIBRARY_PATH=/home/nitro/valheim_server/linux64:$LD_LIBRARY_PATH
# comment these out when not debugging
# Environment=BOX64_LOG=2
# Environment=BOX64_SHOWBT=1
# Environment=BOX64_TRACE_FILE=/home/nitro/valheim_server/Box64_DumpLog.txt
# Environment=BOX64_TRACE_COLOR=1
Environment=BOX64_DYNAREC_STRONGMEM=3
Environment=BOX64_DYNAREC_BIGBLOCK=3
Environment=BOX64_DYNAREC_BLEEDING_EDGE=0
from box64.
@nitroinferno depending on how you installed box64 but if you built it yourself after cloning the repository you could enter the folder, run git fetch; git checkout main; git pull
, then cd build; make -j "$(nproc)"; sudo make install
.
You can then verify the version with box64 --version
.
As for the cpu load, it could be due the lower cpu frequency on the raspberry pi 4 (1.5GHz).
Unfortunately I can't say what the Ampere instances in OCI run at exactly but what I can find it seem that they run at about 3GHz.
Regarding threads, currently my OCI instance runs with 40 threads for Valheim with box64 v0.2.7-ea86b0e3
and a load average of about 10% (currently no players online).
I've attached strace to see if I see anything similar regarding signals.
Edit: server crash, nothing from strace.
from box64.
Good and bad news, server crashed after about 3.5 hours, this was without any variables set other than LOG and TRACEFILE.
Tracefile did not show anything related to the crash itself.
Just restarted it to get another timeframe for comparison then I'll start looking into adjusting box64 configurations.
Update: second run lasted 2 hours.
On the second run I did attach strace shortly after it had started.
A couple of SEGV, PWR and XCPU signal were captured.
I will start looking into configuring box64 now.
from box64.
With the exact same config file (strongmem parameter), latest box64 is not stabble with server?
from box64.
With the exact same config file (strongmem parameter), latest box64 is not stabble with server?
I tried running latest box64 with the following configuration but it will not start up correctly.
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=3
It gets to a point shortly after startup (after about about 10-15 seconds) where it logs the following and locks completely.
02/18/2024 16:52:16: Fetching PlatformPrefs 'GuiScale' before loading defaults
On a normal startup, this line stay for just a few moments until the next lines pop up, like:
02/18/2024 16:53:41: Fetching PlatformPrefs 'GuiScale' before loading defaults
02/18/2024 16:53:41: Fetching PlatformPrefs 'GuiScale' before loading defaults
Privilege Multiplayer is not known on this platform. Privilege therefore is granted without check...
Privilege UserGeneratedContent is not known on this platform. Privilege therefore is granted without check...
I tried adjusting strongmem up to 4, no luck as of yet.
Will continue trying.
The best so far where I've been able to connect is with latest box64 and the following configuration:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=0
Update: Seem like bigblock was causing me some issues, got it running now with the following:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=1
As in I had to explicitly set bigblock to 0
Update 2: So far the server have been running for 24 hours using STRONGMEM=2
, full config:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=2
BOX64_LOG=1
BOX64_TRACE_FILE=/home/ubuntu/valheim.box64.log
Update 3: Server still chugging along (48hours) using the above mentioned configuration (from Update 2).
from box64.
Also, note that the new box64 has a secret strongmem=4 parameter, that should be equivalent to the strongmem=3 of v0.2.6
That looks promising. After setting the parameters to:
[valheim_server.x86_64]
BOX64_DYNAREC_STRONGMEM=4
BOX64_DYNAREC_BLEEDING_EDGE=0
My OCI instance is now running the server for 11 hours straight without crashing. That is the longest it was able to run since November last year. On a side note, I noticed the CPU usage for the process increased considerably, is that expected with strongmem = 4?
I'm on v0.2.7 5924a8e.
from box64.
3 days in and the server have been behaving really nicely using the following configuration on v0.2.7-ea86b0e3.
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=2
I have not been able to play much but again hopping onto it every now and then, the important part is that the server is running, which it was barely able to do before.
OCI Ampere instance runs on 2 core and 12GB ram, the Valheim server itself is running about 30-40% cpu and 2.0-2.5GB ram. (Load average: 0.46 0.46 0.50).
I did drop a comment in my guide letting people know of a procedure if they wanted to try out v0.2.6, using the parameters mentioned in #1182 (comment), so far I've yet to hear anything (which could mean either no one have tried it yet or they are still testing. :)
from box64.
Hi, sorry if I'm not good at explaining.
I'm running a server on a raspberry pi 5 with crossplay enabled. I have friends with PC and Xbox.
If just one type of platform is connected everything work well and we can play for hours but if both are connected the server crash every 10 minutes.
Here the crash report:
=================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: Native Crash Reporting
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: Got a SIGSEGV while executing native code. This usually indicates
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: a fatal error in the mono runtime or one of the native libraries
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: used by your application.
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: Native stacktrace:
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: 0x3f031151f2 - /home/rpi/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: 0x3f030bdecd - /home/rpi/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_unity_backtrace_from_context
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: 0x3f03110bd1 - /home/rpi/valheim_server/valheim_server_Data/MonoBleedingEdge/x86_64/libmonobdwgc-2.0.so : mono_breakpoint_clean_code
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: 0x3f056f8d30 - /home/rpi/valheim_server/valheim_server_Data/Plugins/libparty.so : _Z11DbgLogBytesPKcmPKv
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: 0x7ef00d08f0 - Unknown
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: Telemetry Dumper:
Feb 28 14:56:27 rpi5 valheim_server.x86_64[6271]: =================================================================
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545122152512x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545823518784x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545800646720x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545079025728x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x547474108480x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545831448640x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x546608496704x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6360]: Could not exec mono-hang-watchdog, expected on path '/home/rpi/valheim_server/valheim_server_Data/MonoBleedingEdge/etc/../bin/mono-hang-watchdog' (errno 2)
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x547006951488x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x547923882048x from 0x548008972352x
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6271]: Pkilling 0x545811853376x from 0x548008972352x
Feb 28 14:56:28 rpi5 systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Feb 28 14:56:28 rpi5 valheim_server.x86_64[6360]: Error: PltResolver: Symbol sigset(optver 2: sigset@GLIBC_2.2.5) not found, cannot apply R_X86_64_JUMP_SLOT 0x3f01d59630 (0x3f01cc3bb6) in UnityPlayer.so
Feb 28 14:56:28 rpi5 systemd[1]: valheim.service: Failed with result 'signal'.
My settings:
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL ATOMICS SHA1 SHA2 PageSize:4096 Running on Cortex-A76 with 4 Cores
Params database has 60 entries
Params database has 60 entries
Box64 with Dynarec v0.2.7 f02d5fc built on Feb 23 2024 22:59:09
[ valheim_server.x86_64] BOX64_DYNAREC_BLEEDING_EDGE=0 BOX64_DYNAREC_STRONGMEM=1 BOX64_DYNAREC_BIGBLOCK=0
Any help? thank you
from box64.
Update from my last comment #1182 (comment).
Almost forgot about the server since I haven't had time to play over the last week, but just connected to it and is still running with the following configuration (also mentioned in previous comment)
# v0.2.7-ea86b0e3
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_BIGBLOCK=0
BOX64_DYNAREC_STRONGMEM=2
● valheim_server.service - Valheim Dedicated Server
Loaded: loaded (/home/ubuntu/.config/systemd/user/valheim_server.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2024-02-18 21:57:20 UTC; 1 week 2 days ago
A few people in my guide have also started trying the procedure using v0.2.6
, some even with crossplay enabled.
So far I've yet to hear any updates which might be good news.
In my case I'm happy with the results, as soon as I hear more from the few extra people testing, I'll update here.
from box64.
In my case I'm happy with the results, as soon as I hear more from the few extra people testing, I'll update here.
Hello, I can also help with testing. I have a "VM.Standard.A1.Flex" instance with 20GB memory. I am still new to this stuff so some of these things are beyond me, but would you be able to help me with a couple questions?
-
I was using this to run a minecraft server but now wish to play valheim. Would it be possible to run the mc server with 15GB and valheim with 5GB on the same instance? Or would that mess with things?
-
If I need to dedicate the instance to valheim, is 20GB overkill? Would it still run fine?
Thanks!
from box64.
@dre3002 that should be fine.
My instance (although not doing much at the moment) has 12GB, but the valheim server itself uses about 20% of that (so 3GB), you might need to adjust the memory limits for both servers depending on load, but 5GB should be fine for initial testing at least :)
from box64.
My server has been running on my raspberry pi 4 now that only has 4GB of RAM for over a week with no crashes! Me and my friend hop on and play for hours at a time no problems. Still using the version I mentioned before: v0.2.7 57ca9df
Valheim developers minimum recommended RAM is 8GB. So 20 is probably a little overkill 10 GB should be fine.
Does it work with crossplay too?
from box64.
Upon updating box64 from v. 0.2.7 ed2697d to v. 0.2.7 eda857c, my Valheim OCI server is now once again silently crashing.
Before, I was able to keep it running stable with:
[valheim_server.x86_64]
BOX64_DYNAREC_BLEEDING_EDGE=0
BOX64_DYNAREC_STRONGMEM=4
But now it doesn't make any difference to use those values.
Also, the logs are showing these warnings now:
Warning: Weak Symbol _ITM_memcpyRtWn not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624f060 (0x9c0f6)
Warning: Weak Symbol _ITM_RU1 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624f6a0 (0x9cd76)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624fb00 (0x9d636)
Warning: Weak Symbol _ITM_RU8 not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff0624fff8 (0x9e026)
Warning: Weak Symbol _ITM_memcpyRnWt not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff062504a8 (0x9e986)
Warning: Weak Symbol _ZGTtnam not found, cannot apply R_X86_64_JUMP_SLOT @0x7fff06250c88 (0x9f946)
Is anyone else having a similar issue?
from box64.
I forgot about the server, bogged down with work.
Just hopped on the server and it's still chugging along using (v0.2.7 eda857c)
@tiagojofran you didn't mention, but did you also update the Valheim server?
Mine is running Valheim version: l-0.217.38 (network version 20)
I'll update it now, restart it and let it run for a while.
Updated: Just updated the server to Valheim l-0.217.46 (network version 23)
, seem to have started normally, will let it run for a couple of hours.
from box64.
Hm, I've not been able to replicate the issue @tiagojofran
Server have now been running for 24 hours using Box64 with Dynarec v0.2.7 eda857cb
and Valheim l-0.217.46 (network version 23)
Shouldn't make much of a difference, but these are the environment variables I use for box64.
Applying BOX64_LOG=1
Applying BOX64_DYNAREC_BIGBLOCK=0
Applying BOX64_DYNAREC_STRONGMEM=2
Applying BOX64_DYNAREC_BLEEDING_EDGE=0
Update 2024.04.17: server is still chugging along with the version mentioned above.
from box64.
@husjon hoping you can shed some light on the use of v0.2.7 eda857c or v0.2.7 eda857c. When you stated its still chugging along with respect to v0.2.7 eda857c, did it have faults as I do below? Most of these faults are due to mono lib it seems since these generate the mono-blob files.
I am still using v0.2.6 stable branch with the following params.
BOX64_LOG=1
BOX64_DYNAREC_BIGBLOCK=1
BOX64_DYNAREC_STRONGMEM=2
BOX64_DYNAREC_BLEEDING_EDGE=0
For whatever reason if I set BIGBLOCK to 0, it causes a lot of issues on a pi, I flagged multiple short duration faults on Apr 28th when I tried to use Bigblock=0. Either way for the most part it runs smooth anywhere from 12-24hrs. I am thinking about rolling it forward to v0.2.7 eda857c, however wasn't sure if that was less faulty with respect to mono related crashes, or whether v0.2.7 eda857c was either.
nitro@raspberrypi:~ $ journalctl -u valheim | grep -i exited
Mar 04 13:02:06 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
Mar 04 13:13:17 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
Mar 04 21:03:57 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
Mar 05 23:03:18 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 08 06:03:06 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 10 09:36:38 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 11 04:08:51 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 11 22:21:56 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 14 02:02:16 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 18 04:39:19 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 19 00:13:36 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 19 14:46:33 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 21 06:03:23 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 21 22:08:01 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 27 13:42:31 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Mar 28 08:59:51 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 29 16:48:01 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Mar 30 00:19:53 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 01 07:07:59 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 02 08:55:50 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 02 16:28:19 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 04 10:43:54 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 08 16:03:09 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 08 23:50:41 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 09 23:22:53 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 11 10:55:55 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 12 15:43:33 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 15 15:40:13 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 18 12:22:02 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 19 11:27:54 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
Apr 19 20:43:00 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 20 22:19:27 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 21 12:08:44 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 21 12:12:38 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 22 04:03:24 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 23 14:15:34 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 23 19:50:41 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 26 09:05:31 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 26 12:27:22 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 27 09:02:43 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 27 23:57:28 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
NOTE:~ $ Apr 28 20:32:54 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
NOTE:~ $ Apr 28 21:05:41 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
NOTE:~ $ Apr 28 21:09:31 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
NOTE:~ $ Apr 28 21:45:20 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=9/KILL
Apr 29 09:09:45 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
Apr 29 12:23:10 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
Apr 30 11:27:14 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=5/TRAP
May 01 19:19:13 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
May 02 00:08:26 raspberrypi systemd[1]: valheim.service: Main process exited, code=killed, status=6/ABRT
from box64.
@nitroinferno from what I've gathered from the previous comments, there is a quite a difference running it on OCI versus a Raspberry Pi.
BIGBLOCK seem to work fine on OCI Ampere instances, but not on a raspberry.
As for status on the server, it is still running.
ubuntu@game-server:~$ systemctl --user status valheim_server
● valheim_server.service - Valheim Dedicated Server
Loaded: loaded (/home/ubuntu/.config/systemd/user/valheim_server.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2024-04-12 16:46:45 UTC; 2 weeks 6 days ago
I see you have a Raspberry Pi 4, so it will not be an exact match but I'll do some testing on my Raspberry Pi 5 (I unfortunately do not have a Pi 4 available) over the weekend.
(Side note: I am using the same build parameters as RPI4, -D RPI4ARM64=1 -D CMAKE_BUILD_TYPE=RelWithDebInfo
since my RPI5 is not using 16K pages.)
from box64.
@nitroinferno I've had the server running on my RPI 5 for 2 days now using eda857c
I haven't played on it, just let it run on its own.
I'm not sure if the issue you're having is an isolated case for RPI 4.
What are the specs of the RPI 4 you have?
My RPI 5 is the 4GB model.
pi@raspberrypi:~ $ box64 --version | grep built
Box64 with Dynarec v0.2.7 eda857cb built on May 2 2024 21:21:30
pi@raspberrypi:~ $ systemctl --user status valheim_server.service
● valheim_server.service - Valheim Dedicated Server
Loaded: loaded (/home/pi/.config/systemd/user/valheim_server.service; enabled; preset: enabled)
Active: active (running) since Thu 2024-05-02 22:54:20 CEST; 2 days ago
from box64.
I was partially wrong in my previous comment.
It seem like the server have deadlocked since nothing has been logged to journalctl since May 3rd.
Actually after trying to connect to it, it seem like it is still running (to some degree), but is not able to handle connections.
I get the following entries in journalctl when trying to connect
May 03 12:25:06 raspberrypi valheim_server.x86_64[10338]: 05/03/2024 12:25:06: No autobackup needed yet...
May 03 12:26:09 raspberrypi valheim_server.x86_64[10338]: 05/03/2024 12:26:09: Connections 0 ZDOS:81 sent:0 recv:0
May 03 12:36:09 raspberrypi valheim_server.x86_64[10338]: 05/03/2024 12:36:09: Connections 0 ZDOS:81 sent:0 recv:0
May 03 12:46:09 raspberrypi valheim_server.x86_64[10338]: 05/03/2024 12:46:09: Connections 0 ZDOS:81 sent:0 recv:0
May 05 15:22:44 raspberrypi valheim_server.x86_64[10338]: src/steamnetworkingsockets/clientlib/steamnetworkingsockets_connections.cpp (1115) : Assertion Failed: Unexpected auth avail -100 (Expired)
May 05 15:24:03 raspberrypi valheim_server.x86_64[10338]: src/steamnetworkingsockets/clientlib/steamnetworkingsockets_connections.cpp (1115) : Assertion Failed: Unexpected auth avail -100 (Expired)
May 05 15:24:03 raspberrypi valheim_server.x86_64[10338]: src/steamnetworkingsockets/clientlib/steamnetworkingsockets_connections.cpp (1115) : Assertion Failed: Unexpected auth avail -100 (Expired)
I'm gonna do an upgrade of the OS, reboot and restart the server, then let it run for a few more days.
from box64.
Seem like it deadlocked once again after about 30 hours on my RPI5.
I'll try to adjust some of the box64rc parameters to see if I can find something that works a bit better.
from box64.
I am also trying to get a server working on a RPI5 (8GB) with box64. I tried a few of the settings for box64rc mentioned here but haven't been successful. Longest I had the server running before the silent crash was only an hour. Admittedly I can't figure out how to roll my box64 back to a different version so I have only been using the somewhat latest box64 v0.2.7 ecf1902 .
Appreciate all the work everyone has done so far - I will be sure to update with my settings if I get it stable on my system.
Update: Managed to install v0.2.6 e42001b which didn't seem to make a difference. Crashes pretty consistently after 5 minutes.
from box64.
Glad you got it running, but of course annoying that it didn't work after all :/
Just to make sure that it is picking up the environment variables (if you used the exact ones I mentioned), you should see the following lines shortly after starting it (only if LOG is set to 1 or higher).
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_LOG=1
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_BIGBLOCK=0
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_STRONGMEM=2
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_DYNAREC_BLEEDING_EDGE=0
May 09 23:28:28 raspberrypi valheim_server.x86_64[18757]: Applying BOX64_TRACE_FILE=/home/pi/valheim.box64.log
I have had some success as my server have been running for close to 3 days now using the settings mentioned in my previous comment (#1182 (comment)).
I will however do a restart of the valheim server and do another run to see if it was just a lucky run. :)
from box64.
Almost 48 hours later and the server is still running normally on my RPI 5 using the settings mentioned above.
pi@raspberrypi:~ $ systemctl --user status valheim_server.service
● valheim_server.service - Valheim Dedicated Server
Loaded: loaded (/home/pi/.config/systemd/user/valheim_server.service; enabled; preset: enabled)
Active: active (running) since Sun 2024-05-12 22:56:45 CEST; 1 day 18h ago
Main PID: 883789 (valheim_server.)
Tasks: 41 (limit: 4387)
CPU: 22h 54min 16.810s
CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/valheim_server.service
I set up a similar monitoring solution as you @spwly but instead of restarting I just get a notification so that I can investigate it further. :/
One thing that I just started thinking about is, are you using an SD card as storage medium?
Mine is set up to use a USB stick, I'm using the Samsung BAR Plus USB 3.1 128GB (https://www.samsung.com/au/memory-storage/usb-flash-drive/usb-3-1-flash-drive-bar-plus-128gb-titanium-gray-muf-128be4-apc/)
from box64.
Related Issues (20)
- steamwebhelper requires the Sniper steam runtime. Not found at /home/paul/.local/share/Steam/ubuntu12_64/steam-runtime-sniper, there is a problem with your installation, aborting. HOT 2
- Error loading needed lib libblkid.so.1 HOT 2
- Cannot allocate memory error HOT 8
- Box64 Seems Failing to Handle `.init_array` HOT 5
- Respondus Lockdown Browser - needs libgnutils.so.30 fixed HOT 3
- Error: PltResolver: Symbol cupsSetPasswordCB2 trying to wipe a drive with Active KillDisk HOT 6
- Support `sys_getpgrp` & `sys_getgpid` HOT 1
- Are there some ways to check the wrapped functions?
- Unimplemented 32bits Opcode (00 00 00 00) 64 66 8D 80 00 00 00 00 0F 10 04 08 0F 10 4C HOT 2
- Trying to run intune-portal for our ARM-based linux clients HOT 2
- `BOX64_DYNAREC_TEST` on RISC-V is Failing HOT 7
- DanserGo: need help with acquiring Shared Object files HOT 2
- Unexpected Behaviors when Using RISC-V Extension "zbs" HOT 1
- Trying to install dotnet8 with winetricks on PiOS Bookworm HOT 7
- Unexpected Dynarec-Interpreter Difference on `cmp` Instruction HOT 4
- Trying to run Windows version of Steam through wine new wow64 mode HOT 4
- Error while trying to install dotnet 8 HOT 2
- Wine AppImage Won't Run, Missing Syscall HOT 1
- How to Count the Number of Executions of Each Dynablock in Box64? HOT 7
- 8c5752de23ac421025032e405ca3168191ae7a33 dynarec breaks rkbin's boot_merger HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from box64.