native support for screen (and tmux?)

[aspiers]

It seems like a pretty common use case to want to run mkcloud inside screen. I guess there are a few reasons, e.g.

• mkcloud runs generally take a long time, so this protects against network outages
• mkcloud runs generate a lot of output, and screen/tmux can capture output in the scroll-back buffer or even in a log file (although mkcloud needs to automatically log itself to a file #1191 could take care of that separately)
• It's useful to be able to live-collaborate with others on a cloud.
• mkcloud currently needs to run in a dedicated directory (see mkcloud writes temporary files in cwd #224), so this helps keep separation between multiple clouds on the same machine.

We could either write a wrapper around mkcloud which supports creation of a new screen session for the cloud and reuse of any existing session, or we could add native support for this directly into mkcloud itself. For example:

1. Check if already running inside screen; if so, carry on as normal.
2. Not running inside screen, so check if there is an existing screen session for this cloud. If so, join the session and re-run via exec $0 "$@" or similar.
3. If there is no screen session, create one and re-run the script as in step 2.

A similar approach could be used for tmux.

Is this worth doing? @vuntz This arose from looking at /root/manual.vuntz/start-screen.sh etc. on mkcloud1.

/cc @jdsn @bmwiedemann

One remaining question is how to handle non-interactive invocations, e.g. if you were batch-starting 10 new clouds in parallel.

[jdsn]

We could either write a wrapper around ... or we could add native support ...

I am not sure if its worth the effort. Its a nice idea indeed.
But how many of use need this and how often?
I need it once after an mkcloud host booted. Not sure about other peoples use cases.

Adding such a feature should be doable, but I guess we have other more pressing issues to address.

One remaining question is how to handle non-interactive invocations, e.g. if you were batch-starting 10 new clouds in parallel.

Please, can you give us some of such machines ...

[aspiers]

But how many of use need this and how often?

Answering that question is the whole point of writing use cases, so you could look through the use cases I helpfully suggested and decide for yourself ;-) Probably the most important one is protecting against network outages, which explains why you don't personally feel the urgency, because you're not a remote worker.

Please, can you give us some of such machines ...

We already have one; it's called blacher.

[jdsn]

Probably the most important one is protecting against network outages,

Well, you might wonder that the first thing I do when running an mkcloud run is to start screen.
I also like to be able to dis- and reonnect. Even we have network outages sometimes.

My point was not to question the use of screen/tmux at all. I just wonder if its worth doing it automatically. The fix is just a screen<Enter> away. For me that currently works and does not slow me down.

So if $somebody provides such a feature I will accept it for sure. I would just not invest time into it right now (just MHO).