Apple Terminal startup errors (session save/restore)

Question

(Boring update: it seems that this persists with macOS 15 Sequoia.)

Recently (possibly with the Sonoma update, but possibly even more recently than 14.0), Apple Terminal has been giving the following error on startup (when macOS is set to restore windows, i.e., when System Settings > Close windows when quitting… is unset):

date: illegal time format
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[mm]dd]HH]MM[[cc]yy][.SS] | new_date] [+output_fmt]
-bash: Saving: command not found

or, in the case of zsh,

/Users/jaffe/.zsh_sessions/<random hex guid>.session:2: command not found: Saving

(Sometimes the error messages are somewhat different — the problem is clearly somewhat "non-deterministic" due to whatever race condition is happening.)

Since originally posting this question (see updates below), it has become clear that the error appears to happen in multiple versions of macOS, on Intel and Apple Silicon. It does not appear to be due to installed software or config files.

I have traced this to an error coming from /etc/bashrc_Apple_Terminal (or /etc/zshrc_Αpple_Terminal) which is largely concerned with saving and restoring sessions for the various terminal tabs and windows. (Most of the following will specifically refer to the symptoms with bash but it’s similar for zsh.)

It comes from the lines

    if [ -r "$SHELL_SESSION_FILE" ]; then
    . "$SHELL_SESSION_FILE"
    rm "$SHELL_SESSION_FILE"
    fi

On shell startup, this snippet runs, and then deletes, "$SHELL_SESSION_FILE", which is written at shell exit by the following lines:

    if [ -n "$SHELL_SESSION_FILE" ]; then
        echo -ne '\nSaving session...' >&2
        (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
        declare -F shell_session_save_user_state >/dev/null && shell_session_save_user_state
        shell_session_history_allowed && shell_session_save_history
        echo 'completed.' >&2
    fi

The error occurs because $SHELL_SESSION_FILE incorrectly contains the following text:

Saving session...echo Restored session: "$(/bin/date -r 1698759014 Saving session...)"

rather than echo Restored session: "$(/bin/date -r 1698759014) For some reason, the Saving session... text is appearing in the file (twice!) -- it is being sent to "$SHELL_SESSION_FILE" rather than stderr (via >&2).

I think I didn't make any changes to cause this, but perhaps I am wrong. The directory ~/bash_sessions/ seems to have recent files with this error, and slightly older files (as recent as yesterday!) which don't. I regularly update various packages with homebrew, and I have recently installed Python 3.12 from python.org, but I can't see how they could reach into the guts of shell startup.

---

Update: In fact, I see this even with a new user, and even if I use zsh rather than bash! (Apple Terminal has very similar code for session history management under zsh.) So it seems that some other recent change to my system is causing this. But I suspect it's not simply a Sonoma problem, since it does not appear to be widespread. Yikes!

Update 1a: Note that the code is run via trap shell_session_update EXIT. The error only seems to happen when I exit the shell by quitting Terminal.app, but not when I just use the exit command. (And I've even tried explicitly sending various signals to the shell via kill -n, but I can't seem to induce the error that way.)

Update 2: At least one other person is seeing this! Perhaps this indicates an issue with VS Code?

Update 3: After some back and forth in the comments below, it is clear that the error spans multiple versions of macOS on both Intel and Apple Silicon architectures, and we seem to have eliminated VS Code and possibly Python (we seem to be using different versions and installers) as the cause; I have removed /opt/homebrew and rebooted and still seeing the issue. Is it possible that any of these things somehow "pollutes" the environment -- e.g., /etc/ -- in some way that remains in place?

Update 4: Inspired by an interaction over on TidBits, I tried using Howard Oakley's excellent sandboxed lightweight VM, ViableS. I installed nothing, nada, zip, and added no files to ~/ or anywhere else. But after starting and restarting Terminal.app with a few tabs, and ensuring that "close windows when quitting" is unset, I immediately got the message

/Users/jaffe/.zsh_sessions/<random hex guid>.session:2: command not found: Saving

This seems to point, nearly conclusively, to a macOS bug. But I still don't understand how there are people reporting not seeing it.

---

Is anyone else seeing this? Is anyone explicitly not seeing it? Any ideas what's happening (or even debugging suggestions)?

I've asked a more specific version of this question over on Unix & Linux SA.

Answer 1

I think I figured this out. Running multiple Terminal sessions at shutdown can cause a race condition in writing the history file. See my reply https://stackoverflow.com/questions/62316487/terminal-modified-permanently-by-vscode/77424721#77424721

But it doesn't have anything to do with VSCode; it's an Apple bug. Here's my fix:

scott@Mac-mini-x86 etc $ diff  bashrc_Apple_Terminal.orig bashrc_Apple_Terminal 
215,219c215,223
<       echo -ne '\nSaving session...' >&2
<       (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
<       declare -F shell_session_save_user_state >/dev/null && shell_session_save_user_state
<       shell_session_history_allowed && shell_session_save_history
<       echo 'completed.' >&2
---
>       local save_lock_file="$SHELL_SESSION_DIR/_saving_lockfile"
>       if /usr/bin/shlock -f "${save_lock_file}" -p $$; then
>           (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
>           echo -ne '\nSaving session...' >&2
>           declare -F shell_session_save_user_state >/dev/null && shell_session_save_user_state
>           shell_session_history_allowed && shell_session_save_history
>           echo 'completed.' >&2
>           /bin/rm "${save_lock_file}"
>       fi

Note that it's pretty trivial; it just locks to serialize updating of the history file.

Answer 2

Since I've been asked to do so in .zsh_sessions producing an error I post here the fact that commenting out the echo line did make the problem disappear in a similar case:

I commented out the echo -ne line in etc/zshrc_Apple_Terminal and the problem disappeared

  shell_session_save() {
    # Save the current state.
    if [ -n "$SHELL_SESSION_FILE" ]; then
        # echo -ne '\nSaving session...' >&2
        (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
    

As per a user suggestion, so does replacing it by

print -u 2 $'\nSaving session ...' 

Answer 3

I saw this today! Haven't seen it before. I'm on Monterey (12.7.1 21G920).

I rebooted my MacBook today (not installing the update, just a normal reboot). After it restarted, I noticed that it didn't properly restore all my Terminal tabs, but instead restored the state from around Nov 2.

I think I quit the Terminal later again, and after I opened it again, I now saw this in every restored tab:

/Users/kuba/.zsh_sessions/C6E94843-05DC-43CC-933E-5190FC8E0825.session:2: command not found: Saving

I haven't seen that message before. I have a suspicion that it might have something to do with why the Terminal restored tabs state from Nov 2 instead of from before reboot… perhaps they've changed the way how sessions are stored in some recent update? (updated zsh to some new version?)

(More info: I don't have VS Code installed, I have Homebrew installed, but not many packages in it, and also MacPorts.)

Answer 4

Since you have determined that your startup files are causing this (by testing a new user account without any customizations), I would take these next approaches.

1. Run your modified files through a linter. Shell check is excellent in my experience: https://www.shellcheck.net/
2. Set debug flag for bash early in your script.
3. Closely look at any use of the variable you identified as getting stomped.

For item 2, perhaps you can set an alternate shell temporarily and then call bash:

/bin/bash -lixc exit 2>&1 | less

if your <GUID.session> file is unclean - we'll need to pick apart why your customizations are breaking that file generation in the function shell_session_save - on my system this is as follows:

me@mac ~ % which shell_session_save
shell_session_save () {
    if [ -n "$SHELL_SESSION_FILE" ]
    then
        echo -ne '\nSaving session...' >&2
        (
            umask 077
            echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE"
        )
        whence shell_session_save_user_state > /dev/null && shell_session_save_user_state "$SHELL_SESSION_FILE"
        local f
        for f in $shell_session_save_user_state_functions
        do
            $f "$SHELL_SESSION_FILE"
        done
        shell_session_history_allowed && shell_session_save_history
        echo 'completed.' >&2
    fi
}

What’s curious to me is reports of zsh having similar issues.