Dietpi: Concurrent execution warnings mess up tmux-continuum

[wallace11]

Required Information:

• DietPi version | 6.16
• Distro version | stretch
• Kernel version | Linux DietPi 4.14.66+ #1 SMP PREEMPT Thu Aug 23 05:59:33 UTC 2018 armv7l GNU/Linux
• SBC device | Odroid XU3/XU4/HC1/HC2 (armv7l)

Additional Information (if applicable):

• Software title | dietpi/func/dietpi-globals and dietpi/func/obtain_network_details
• Was the software title installed freshly or updated/migrated? freshly installed
• Can this issue be replicated on a fresh installation of DietPi? yes

Steps to reproduce:

1. Install tmux
2. Install tpm
3. Install tpm-continuum and tmux-resurrect plugins.
4. Make sure you use the option set -g @continuum-restore 'on' to restore sessions automatically.
5. Create a new tmux session with at least 2 panes.
6. Save it via prefix+ctrl+s.
7. Kill the tmux session kill-server.
8. Re-run tmux.
9. The screen is spammed with errors from running concurrent sessions of obtain_network_details script.

Extra details:

I understand there's a need to check that scripts aren't clashing with each other, but maybe there's a better way to avoid this error?
Hope you find my edge-case most relevant.

[MichaIng]

@wallace11
Thanks for your report.

Jep we need to check for concurrent executions, otherwise scripts could attempt to concurrently access the same files or remove tmp files still needed by the other script, for clean-up.

What we could do in case of uncritical oneshot scripts, is allowing them to fail with just a meaningful error message instead of whiptail prompt.

But I am wondering about spamming (repeating?) such errors with the obtain_network_details script. It is called just once when the new session/terminal window/instance opens and should only take a faction of a second.
Might it be possible that the script hangs on the tmux sessions somehow? Check htop to see if it is really still running. You could try to run it manually, after killing the related process and check for error messages, unresolved loops or something.

With screen (similar to tmux) it works well here btw, so generally concurrent terminal sessions are no issue. But will try to replicate with tmux as well, perhaps it works somehow different there, especially related to the /tmp dir.

[wallace11]

Hi,
Maybe it wasn't clear enough with my report. Continuum plugin allows to restore a previous session upon launching tmux. That means that if I had a session with 4 panes (or screens, for that matter), they would all be restored at the same time upon launching (if they do not exist already, e.g after rebooting).
It's practically like opening multiple sessions at the same time.
I understand that there's a reason for checking for concurrent execution of the same script, but this error message messes up the session restoration, so if I had htop open on one pane and nano on another, it would show this error message instead of restoring them (effectively disrupting the restore operation).

Hope this the issue is clearer now.

Edit: By the way, I could confirm this by manually editing dietpi-globals. The restoration would return to normal, but it would mess up other dietpi-related stuff.

[MichaIng]

@wallace11
Ah sorry, jep that makes everything crystal clear, I did not go on checking what the plugin does.

Okay, so we cannot (should not) skip the concurrency check on any script, but we could add two options in how to handle concurrency, which we can then apply in case of login script oneshot calls and possibly in some other cases:

1. Silently (or showing a processing message?) wait for the concurrent script to close/finish for a certain max time, rechecking e.g. every second (or 10 times a second?), then start if concurrency got resolved. Could be done simply via WAIT_MAX=[0-9]+ variable. After max time reached, whiptail window can be shown.
2. Show terminal message (or nothing?) only instead of whiptail prompt. Still spammy but at least no user input required. This can currently already be achieved via G_USER_INPUTS=0, but we could also add a separate variable for this. Combination of both should be possible.

The second of course is simpler and would not be an issue in this particular case. Only the login banner might show wrong IP info, if it changed or was applied not yet during boot script, or might throw an error, if it want's to scrape /DietPi/dietpi/.network in exactly the time this is being updated by obtain_network_details script. Hmm yeah, waiting is simply more bullet/error prove 🤔.

However we will think about it and implement a solution with v6.18.
Until then, I think the simplest solution for now is to simply comment the line /DietPi/dietpi/func/obtain_network_details inside /DietPi/dietpi/func/dietpi-banner. As said, as long as your IP does not randomly change during device is running or because it is a mobile device, switching between WiFi SSIDs, then this should not affect the anyway only visual IP info in the banner.

[Fourdee]

@wallace11

Hi,

We added a global var to v6.17, which allows you to override the concurrent checks for special use cases:

export G_INIT_ALLOW_CONCURRENT=1

In theory, if tmux copies existing exports, you can run this command before Create a new tmux session with at least 2 panes..
Failing that, you'd need to somehow set G_INIT_ALLOW_CONCURRENT=1 at the 1st instance of tmux session generation.

I have 0 experience with tmux, however, if the above does not work, please let us know.

[MichaIng]

@Fourdee
Nice, didn't recognize that 👍.

However note that this is a bid dangerous to leave in place (exported), especially when you use several terminal windows. Concurrent executions can (and in many cases will surely) break each other. In case of banner/obtain network details however only visually.

So I still think the G_INIT_WAIT_CONCURRENT= (or seconds but allow floating number?) has it's benefits. This can be added to all our oneshot scripts code wise where we can estimate execution time and no manual user input as expected (that would break any execution time guess).

[Fourdee]

@MichaIng

However note that this is a bid dangerous to leave in place (exported), especially when you use several terminal windows

Yep, no guarantee issues will not occur. However, it will allow the user to try a possible workaround.

[wallace11]

@Fourdee
Amazing! Adding the following line to my .bashrc just solved the problem like magic:

export G_INIT_ALLOW_CONCURRENT=1

Regarding what @MichaIng suggested: I personally do think that in terms of design it's generally a much safer approach. My setup is used for my home server so there's nothing "unexpected" the system might run into, but in case of concurrent executions who knows what could go wrong ;)

BTW, if you're using GNU Screen then you should definitely check out tmux, it does exactly what Screen does with way more functionality baked in ;)

Thank you so much for the responsiveness and the hard work!

[Fourdee]

@MichaIng

So I still think the G_INIT_WAIT_CONCURRENT= (or seconds but allow floating number?) has it's benefits.

Yep could work, allow for a while loop with timeout based on G_INIT_WAIT_CONCURRENT=X seconds.

[Fourdee]

@wallace11

BTW, if you're using GNU Screen then you should definitely check out tmux, it does exactly what Screen does with way more functionality baked in ;)

Sounds great, although, I'am a little spoilt, I run 5+ SBC's at any one time 🤣, Just a case of SSH'ing on demand 😄

[Fourdee]

@MichaIng

G_INIT_WAIT_CONCURRENT

Done 👍

@wallace11

In v6.18, you may want to use the above, and, set a higher value (seconds). eg:

export G_INIT_WAIT_CONCURRENT=20

Above will wait for application to finish, before running, instead of simply allowing concurrent (which may cause issues).

Completed.