Andrew Clayton

Are you getting coredumps? (might not be enabled) I would really like to see a backtrace from one ```console $ gdb /path/to/unitd /path/to/coredump (gdb) bt full ``` Or if your...

Not really a Unit specific thing... In the container what does ```console $ cat /proc/sys/kernel/core_pattern ``` return? When unit is running what does ```console $ cat /proc/`pidof -s unitd`/limits ```...

OK, so according to that you _should_ be betting core dumps in /tmp/ named `core` or possibly `core.pid` (depending on the setting of /proc/sys/kernel/core_uses_pid). See anything there?

If you find a core file. You can do ```sh $ gdb /path/to/uniid /path/to/corefile (gdb) bt full "Might need to press 'c' to get the full thing" ``` Alternatively if...

Coredumps are a standard UNIX (and other OS's) feature and will generally be generated for any processes that crash, or when receiving a signal whose default action is to coredump,...

Is this not an issue? ``` =================================== FAILURES =================================== __________________ test_python_application_variables[3.10.12] __________________ date_to_sec_epoch = sec_epoch = 1712839114.0 def test_python_application_variables(date_to_sec_epoch, sec_epoch): client.load('variables') body = 'Test body string.' resp = client.http( f"""POST...

Bit of a chicken and egg problem... I think I'd wait for the code change to be merged first, then we won't get failing tests all the time...

The other option would be to have Zhidao merge it via his prll-request, which would be a completely reasonable thing to do...

Yes, waiting's good...

> Does it make sense to release #1162 and #1197 in a single commit? > If released separately, the tests won't pass. Not the same commit. But they could go...