metin-server/m2dev-server
3
0
Fork 1
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

ops: snapshot crash executables

Browse Source
This commit is contained in:
server
2026-04-14 17:05:11 +02:00
parent 0bc6559283
commit 6f16f66543
3 changed files with 107 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/server-management.md
View File

@@ -241,8 +241,9 @@ Each bundle contains:
- listener state from `ss -ltnp`
- tailed runtime `syslog.log` and `syserr.log` files
- metadata for any `core*` files found under `runtime/server/channels`
- metadata for the executable inferred for each core file
If you call it with `--include-cores`, matching core files are copied into the bundle as well.
If you call it with `--include-cores`, matching core files are copied into the bundle as well. In the same mode, the inferred executable files are copied too, so a later redeploy does not destroy your ability to symbolicate the crash with the original binary snapshot.
The runtime units now also declare `LimitCORE=infinity`, so after the next service restart the processes are allowed to emit core dumps when the host kernel/core policy permits it.
@@ -252,4 +253,4 @@ For quick manual crash triage outside the incident bundle flow, use:
metinctl backtrace
```
It defaults to the newest core file under the runtime tree, infers the executable path, and uses `gdb` or `lldb` when present on the host. If no supported debugger is installed, it still prints file/readelf metadata for the core and executable.
It defaults to the newest core file under the runtime tree, infers the executable path, and uses `gdb` or `lldb` when present on the host. If no supported debugger is installed, it still prints file/readelf metadata for the core and executable. If the current executable is newer than the core file, the helper prints an explicit warning because the backtrace may no longer match the crashed binary.