Sessions appear lost when zellij is upgraded

[raphCode]

When zellij is upgraded, for example by the system package manager, any sessions running under the previous version are not visible anymore to new invocations of zellij.
This is because the version number between the old server process and the new client process mismatches. Specifically, zellij sockets for communication between client are in $XDG_RUNTIME_DIR/zellij/<version_number>.

When the system package manager replaces the zellij binary, this makes it non-trivial to recover the old sessions. If the communications protocol did not change between the versions, a symlink from the new version directory to the old suffices to be able to reconnect the session. This is a dangerous workaround however since internal protocol changes might crash the session.
Besides from downloading the old version again, there is no way to recover the binary of the old version, even if the inode is still there as shown by pmap -X.

Possible solutions for server+client on the same machine:

• Change socket directory only on incompatible version bumps, in the hope this happens seldom enough
• Make upgrading the running server / sessions possible
• Provide the old client version even after an upgrade, either by means of the filesystem, or by forking:
  • forking zellij at server startup
  • pausing the child
  • fork again every time a client process is needed

I really like the idea of #387 where server and client are not on the same machine, but this complicates the problem. It makes it more likely as well because different machines may have different zellij versions. My best guess is to re-use the forking solution and send the zellij binary (or only the client part) over the wire to the connecting client, so that the versions can match.

[a-kenji]

When the system package manager replaces the zellij binary, this makes it non-trivial to recover the old sessions.

Ok, this seems ideal for a nix plug.

In earnest, thank you for raising this issue.

Change socket directory only on incompatible version bumps, in the hope this happens seldom enough

We intentionally tie it to the version number. First because every minor version release for us is a breaking change. And I don't think with the architecture changes that are going on at the moment, we can give that guarantee - especially since configuration plays a heavy role here (is someone deciding to run plugins, or not?).

Make upgrading the running server / sessions possible

That sounds awesome, maybe that is possible? I would like to get input on that.

Provide the old client version even after an upgrade, either by means of the filesystem, or by forking

I think that is probably the safest option, and the most achieveable. The old client wouldn't need to start new sessions, only connect to still running sessions. But there are also problems, the old client may not be able to open new tabs safely. It will increase the binary size, but I guess it could be less than we gain with #1177.

[raphCode]

In earnest, thank you for raising this issue.

Glad it is helpful! I added it to my stability tracking issue as well, but I am not sure on this. If someone feels it does not belong there, I'll remove it.

It will increase the binary size

How exactly do do you think it will?

[a-kenji]

How exactly do do you think it will?

I think I misunderstood the proposal a little, I thought you meant
we should ship the old client as well.

I think if we go that route we would need to do that, or?

[raphCode]

That would be a possibility, but I think it is inferior since it increases the binary size. Also it is not even known if the previous version is enough, since the update might skip a version.

My idea was that every server process started keeps a copy of its zellij binary, so that a client with the matching version can be started from that copy.

The copy may be accessible on the filesystem by hardlinking or copying the binary prior to execution or by using the fork() syscall.