Hi there,
Just wondering is there any workaround for when I pause my VM for the day and when I reopen it the following day all my recordings are dead. I tried pausing the recording and unpausing the recording after the VM restarted but that also didn’t restart.
Any tips?
Thanks
David
What guest OS does the VM run?
What do you mean by “dead”?
Any output in the shell which started asciinema rec? Or you’re recording headless, using e.g. systemd service unit?
So the guest VM is Kali and when I mean dead I mean I go to the terminal where asciinema was previously recording and type in further commands and it is no longer recording (unknown to me) following the VM pause.
Can see in the image below I pause at the red line after the first date command and after coming back and issue the second date command the playback in the next screenshot doesn’t register the 2nd date command so the recording has in fact stopped.
The recording is started automatically via zshrc with asciinema rec -i 0.001 /logs/datetime.cast
Hope that helps
Out of curiosity: How does something like
tail -f /var/log/messages
Does this resume putting out new lines after you un-pause the VM?
@Cyb3rC3lt if you can use the latest CLI version (Release v3.0.0-rc.5 · asciinema/asciinema · GitHub) then add --log-file /path/to/asciinema.log option to the rec command. If the issues is related to file writing (I/O) then error message should show up in the log file.
Thanks guys, I will try this and get back to you
Hi guys, here is a screenshot of me carrying out a few commands, then pausing it then replaying the session. I normally want to replay all my sessions as quickly as possible hence the -i 0.0000001.
Here is what appeared in the logs after unpausing:
2025-06-27T08:10:55.862182Z ERROR asciinema::session: output event handler failed: Os { code: 5, kind: Uncategorized, message: "Input/output error" }
Just so you know my use case. As a Pentester I may just pause my VM every night for weeks to keep onto the console data of the client to take as screenshots near the end of the project. I would be using asciinema as a backup in case Kali crashed or something hence my logs are stored on a share with Windows called ‘Console Logs’.
I start it like this via zshrc which was courtesy of GPT - Auto-start asciinema recording and save to /mnt/hgfs/ConsoleLogs if not already started in this shell. Thanks
if [[ -z “$ASCIINEMA_RECORDING_STARTED” && -t 1 ]]; then
export ASCIINEMA_RECORDING_STARTED=1
asciinema rec -i 0.001 --log-file ~/asciinema.log /mnt/hgfs/ConsoleLogs/$(date +%H-%M-%S_“%d-%m-%Y”).cast
exit
fi
I bet it’s because the remote share you are trying to write to has not been mounted yet when the process tries to resume and then it exits.
Please try to record to the local disk and see if the issue is still there.
Great catch you are right!! After unpausing and continuing on it now caught my ‘ls’ command after unpausing and played it correctly ilustrating it continued to record. This is great.
So I guess I have two options, don’t save to mounted or somehow start the process again after mounting has occurred.
I guess saving to mounted was being paranoid in case Linux completely broke so maybe locally isnt the worst solution or maybe I save it locally and have the logs uploaded to cloud every so often to be backed up.
Thanks very much for sticking with this issue, really appreciated.
I’m glad you solved it.
Btw, about your usage of ASCIINEMA_RECORDING_STARTED env var: asciinema rec sets ASCIINEMA_REC=1 env var automatically so it’s enough to check for its presence, no need to set your own var.
Thanks that’s really good to know
