After resuming from a hybrid-sleep, I can log in (swaylock) and initially it seems ok - pwd, journalctl -xe run as expected in the shell still open from when I put it to sleep.
After a short while though, tens of seconds, when I'd exited journalctl (I just wanted to confirm it had actually been asleep) CPU load increases, I hear the fan spin up, and anything I try to run in the same shell (pwd again, say) results in a SIGSEGV - address boundary error.
Consequently, I can't even issue a shutdown command, so I have to force it off with the power button. Once rebooted, journalctl --boot=-1 has no entries from after it went to sleep, like it never woke. I assume when I saw them they were stored only in RAM, and when I shut down it was unable to write them to disk with the same segfault.
The behaviour is quite erratic - after drafting the above I tested again and was able to 'log in' (bypass swaylock) by entering a single key, not my full password, but any command I tried to run in the open (resumed) shells crashed the terminal emulator, and as before I couldn't re-open any more (the command run by my keybinding for that presumably segfaulted too).
Any ideas what the cause could be? Or even how I can debug this without access to the logs when the system is stable?
Some possibly relevant info, I'll edit in more if anyone can suggest what might be relevant/suspect:
# /etc/systemd/system/swapfile.swap
[Unit]
Description=providing a swapfile
[Swap]
What=/swapfile
Priority=20
[Install]
WantedBy=multi-user.target
# /etc/systemd/system/swapfile-creation.service
[Unit]
Description=creating a swap file at /swapfile
ConditionPathExists=!/swapfile
Before=swapfile.swap
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'dd if=/dev/zero of=/swapfile bs=1M count="$(expr "$(cat /sys/power/image_size)" / 1024 / 1024)" status=progress'
ExecStart=/usr/bin/chmod 600 /swapfile
ExecStart=/usr/bin/mkswap /swapfile
[Install]
RequiredBy=swapfile.swap
I was going to include the systemd-boot entry (or script I used to create it) but actually realised I haven't tested from power loss - this is occurring when resuming from RAM. I will double check that the (unused) suspense to disk isn't somehow the culprit, that it doesn't work when resuming from a plain systemctl suspend.
