[v2] discovering if user is actually using code-server (for idle check - can do in v1)

[antofthy]

Environment: A docker swarm running code-server development environments for multiple users simultaneously (teaching course).

Previously

code-server v1, will log to files in ".cache/code-server/logs" added
a line every time the users browser contacts the running code-server.
This happens at least every 5 minutes (on the dot), while the user has
a open browser pointing to "code-server".

This let me implement a check looking at when these log files last
updated to determine when the user last had a browser open to
code-server. This check could then shutdown the docker container
for users that have not used there code-server for some time.

That is we have implemented idle timeout for the docker instances.
This is vital for the system to keep things running smoothly for
the multi-user docker swarm.

So far I have found no equivalent to implement idle timeout in
code-server v2.

Suggestion.

Provide a 'heartbeat' option/file, that is 'touched' (does not have to
write anything but it could, just have the file timestamp updated),
whenever "code-server" is contacted by the users browser.

This will make idle checking a lot easier too as it not need to search
for the latest log file, just the one heartbeat file.

However a log file file (as in v1) will be fine too.

Or prehaps you have some other suggestion.

PS: Code-server v2 does generate logs whenever the user opens a file. The log is for it attempting to find a 'git' repository for the file, and failing.
But it is not really a good idle/in-use indicator.

[sr229]

@antofthy So you're using this specific log file to audit user access if I'm correct?

[antofthy]

Basically yes...

We are currently still using v1, for a software development environment for 150 separate users (students). And are keen to update to version 2 due to the memory usage of version 1.

For version 1, we are looking for updates to the latest file in the users home matching...

$HOME/.cache/code-server/logs/[0-9]*/sharedprocess.log

The file timestamp (not content) being used to determine when the user last had there browser connected to code-server. We clear all these files when the users container is started so the above pattern generally only ever matches one such file. This file gets updated by code-server v1 every 5 minutes while the user has there browser connected. With an entry like...

[2019-09-01 18:41:48.630] [sharedprocess] [info] Scanned user extensions: 0

It made for great way to determine when the user was no longer using their container, so we can shut it down after being idle for more than an hour.

I actually did not care what was logged, only that some file was being updated while code-server was in use, so that a 'idle time' could be determined. I have not found anything similar in version 2

The alternative was to constantly scan a large volumes of web logs to determine when browsers actually successfully contacted code-server, probably involving a data file to note previous contact times. All of which would have been complex, time consuming and process intensive.

It would be a very minor addition to code-server to have it touch (or log) to some user file, but one that would be immensely valuable in the administration of multiple user code-server containers.

ASIDE: code-server is not only used for development, it is also the users only method of getting a terminal CLI access to their container, which could be running on a number of different nodes of a docker swarm (via a ingress web proxy). Without code-server to provide terminal access, the system would have been basically impossible to scale beyond a single node (allowing SSH command line access to be provided).

[sr229]

We'll see what we can do.

CC @code-asher

[antofthy]

A touch, or update of code-server v2 log file...
$HOME/.local/share/code-server/logs/*/remoteagent.log
OR
$HOME/.local/share/code-server/User/state/*.json
would be ideal.

Just something every 5 to 10 minutes, whenever the web browser contacts server looking for directory/file updates. Basically saying, user is still has it open in the browser.

These files do not update if browser is just sitting there (user may have a unsaved file).

[jeasonstudio]

@antofthy I use code-server@v1 behind a proxy and count the number of websocket connections. Maybe you can try this on v2.

[antofthy]

@jeasonstudio How are you getting that information? Is your proxy a docker service?

Anything would be better than trying to parse web logs!

[code-asher]

The Scanned user extensions line every five minutes actually sounds like a bug haha. We could certainly log periodically to a file while there is at least one active connection to code-server.

One thing we wanted to do is have the ability to open a new file from the command line in the running browser instance. The way to do that would be to have a socket that code-server listens on to get file open requests.

So I'm just thinking out loud but another idea would be to use that same socket to emit events like "connect" and "disconnect" and something could then sit on that and listen. Or maybe we add a command like code-server --status which uses the socket to query the number of open connections or maybe a JSON blob which would contain the number of connections.

[code-asher]

And the time since last connection. This would just be if the browser is actively connected or not though, but we could probably send actual idle info from the browser as well.

[antofthy]

They are some nice ideas, though not as versatile or even as simple as logging, or even just touching, a file. I don't even mind if the file is overwritten, or even deleted or re-created.

Point.. I am not looking at the content of the file for code-server v1, (I only mantioned that so you can see what code-server was logging) just the update time of the file in the file system. That is I don'' even open the file for the idle check, just look at the file attributes. having to parse the file would have been slower!

Also this is part of a larger docker swarm of many docker containers running code-server. So while code-server is running inside a docker container. The idle test that is being run is testing the code-server log files, outside the docker container. That way it can then shutdown the container if it has been idle for some time. In fact the idle test of the files may not even be on the same docker node (machine) the docker container is running on! EG: the container is on a 'worker' node, while the idle check on the code-server log file is being done on the 'master' node of a larger docker swarm. The files being on a network file system (SAN) across all the workers, and mounted as appropriate into the docker containers.

This is why a file update (even if it is just a touch) is a good idea, as the status (idleness) of the code-server is then available to all systems that has access to the log files. Very practical.

[code-asher]

Makes sense.

[antofthy]

That would be perfect. Look forward to seeing this on the next code-server release.