-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rememberchannelduration option is ignored after restarting murmur #5639
Comments
Looking back at the conversation in #4147 it seems that the reasoning for clearing The Since timing the update of So I guess the first issue you found is actually code working as intended (though we should probably add a comment to that line explaining why it is there). |
Well, I can certainly create a pull request for a fix, but I think there is still a problem with the situation here...
If we fix 2) without touching 1) that means that all clients will connect to the root channel instead of their last channel, if the server was restarted independent of their actual Can we reliably assume that If murmur saves its starting datetime, we can use that to compare to I think if we are careful about using the correct values at the correct time, this procedure will not produce errors (?) I would appreciate, if someone would double-check my logical reasoning. |
Indeed. However, I think in this case the argument could be made that by restarting the server, you essentially also restart from a clean slate and thus start connecting to Root. It would certainly be not ideal though.
This sounds reasonable to me. I can't come with a scenario in which this assumption would break 🤔
Do you intend to use the server's starting datetime as a replacement for However, I think the first thing that should be tested is whether |
Yes, in an ideal world this would be used as replacement for maximum accuracy. For the sake of simplicity, we could also just assume that invalid
True, but I think there are reasonable scenarios where we do not expect the Here is the neat thing: My logic would work whether the server close routine is improved or not. If I am willing to work on a pull request for my proposed solution, but for improving the server close logic I think I lack the necessary experience in the mumble code base. Maybe a complete test and audit of the disconnect logic would deserve its own Issue. Do you want me to start working on the above logic? |
Yes, please. In so doing, maybe you could also just test whether |
@Krzmbrzl I have two questions regarding the implementation:
Edit: Nevermind, I found |
With the The server does NOT update Do you want me to try more signals or scenarios? |
No idea, why this was done in this way. Looking at this now, it does indeed appear a bit odd 👀
Okay, thanks for testing this. In that case I guess we'll have to look into that eventually...
Nah, I think this is sufficient, thanks! |
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639
…logic The previous implementation of rememberchannelduration (#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of #4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes #5639
The previous implementation of rememberchannelduration (mumble-voip#4147) acknowledged the unreliability of the last_disconnect database field. It used a workaround to set the last_disconnect field to NULL for every user on every start of the mumble server. However, with a default behavior for NULL, this created the unintended side-effect that rememberchannel was erroneously used for every user on their first connection after a server restart. This new implementation reverts the workaround of mumble-voip#4147 and uses the last_active database field to check if last_disconnect is reliable. If last_disconnect is unreliable, it will now use the server uptime and compare it to rememberchanneduration. We expect last_disconnect to be unreliable when the server was shut down while clients are still connected. Fixes mumble-voip#5639 (cherry picked from commit ccbf407)
Description
We use the
rememberchannelduration
server option on our servers. Last used channels are supposed to be remembered for 5 minutes for potential connection losses and such, but otherwise clients are expected to connect directly to the root channel. This usually works as expected. However, the murmur server is restarted over night every couple of weeks for maintenance.Expected Behavior:
The server restart has no effect on the behavior of
rememberchannelduration
. Clients connect to the root channel, except when they reconnect within the specified grace period.Actual Behavior:
On the first connection of a client after the server restarted the remembered channel is used, even if the
rememberchannelduration
has long expired.Steps to reproduce
rememberchannelduration > 0
,rememberchannel = true
and multiple permanent channelsrememberchannelduration
expireMumble version
1.4.0
Mumble component
Server
OS
Linux
Reproducible?
Yes
Additional information
Offending Code:
Upon examining the code of the feature pull request #4147 we can see two things which are handled weirdly/wrongly:
last_disconnect
field is set toNULL
when starting murmur. CODEServerDB.cpp
is broken whenrememberchannel == true
,rememberchannelduration > 0
andlast_disconnect
is equal toNULL
.rememberchannelduration
is ignored and the server assigns the remembered channel anyway (as long as the channel still exists). CODEProposed Solution:
To fix this murmur could
last_disconnect
toNULL
when starting.ServerDB.cpp
by returning-1
in caselast_disconnect
is equal toNULL
ANDrememberchannelduration > 0
.Or possibly both.
Relevant log output
No response
Screenshots
No response
The text was updated successfully, but these errors were encountered: