-
Notifications
You must be signed in to change notification settings - Fork 654
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
Update libssh to 0.11.1 #3735
base: main
Are you sure you want to change the base?
Update libssh to 0.11.1 #3735
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3735 +/- ##
==========================================
+ Coverage 88.94% 89.00% +0.05%
==========================================
Files 256 255 -1
Lines 14584 14599 +15
==========================================
+ Hits 12972 12994 +22
+ Misses 1612 1605 -7 ☔ View full report in Codecov by Sentry. |
da5d0fc
to
79996f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work Trevor, thanks. I ask only for some unit tests for the new code. Other than that, +1 on my secondary review.
Some reproduction steps for the issues. Formatting:
Mounts:
|
de690f1
to
96d1a01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @Sploder12
Thanks for the good work, the fix seems to be solid. I only have a few minor comments and questions.
src/sshfs_mount/sshfs_mount.cpp
Outdated
const std::string& target, | ||
const mp::id_mappings& gid_mappings, | ||
const mp::id_mappings& uid_mappings) | ||
: running{true}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should setting running
to be true be in the sftp_thread
as a way of localizing the variable?
It should not be true until the sftp_server
is running, so maybe before sftp_server->run();
is more appropriate. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same intuition, but I believe this needs to be alive right after construction, so that the watchdog doesn't quit before the thread starts.
To avoid confusion, one alternative would be to have an enum to distinguish the running state, instead of a bool. Something like "unstarted, running, stopped". Then in the watchdog condition, look for stopped. The logic would be the same, but it would help readers and future devs not move this and introduce a bug. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ricardo's belief is correct. The watchdog would immediately exit if the thread takes a while to start. I think the enum approach would work well though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, i see, then the enum approach is fine.
: session{ssh_new(), ssh_free}, mut{} | ||
{ | ||
if (session == nullptr) | ||
throw mp::SSHException("could not allocate ssh session"); | ||
|
||
const long timeout_secs = std::chrono::duration_cast<std::chrono::seconds>(timeout).count(); | ||
const long timeout_secs = std::numeric_limits<long>::max(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About this change, I think the timeout_secs
is used to set the SSH_OPTIONS_TIMEOUT
, and this option is the timeout value for ssh session connection establishment wait time (not entire sure about this, hard to find a clear documentation as well). Therefore, having a reasonable value (like the original 20 seconds) seems to makes sense here.
Besides, with your watchdog fix ( which is essentially checking the sftp_threading running together with other SIGQUIT, SIGTERM, SIGHUP signals), the program already behaves correctly. So I am doubting whether we still make the time out change here. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't this a keep-alive timeout? A better var name might help here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The program will not behave correctly with a reasonable timeout unfortunately. After the timeout expires, the sshfs_server process will exit, the watchdog fix makes it so that it doesn't hang. It behaves like a keep-alive timeout, but libssh has no keep-alive messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so it looks like a keep-alive timeout as opposed to ssh session connection establishment wait time, interesting. It is a weird option offered to users though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do have a wondering here though, the SSH_OPTIONS_TIMEOUT
is the a ssh option. If it were a keep-alive timeout, should it be the timeout of ssh session alive? If so, should the multipass shell
hang without mount?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
multipass shell
doesn't hang since it's setup to automatically reconnect. You can see this behavior in #3810 where the SSH session is restarting every 20 seconds. Also with normal use it's much more likely there is some SSH traffic within the 20 seconds compared to SFTP which is likely to not get any traffic for long periods of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR @Sploder12! And nice review as well @georgeliao 😃
A few comments on my secondary review.
src/sshfs_mount/sshfs_mount.cpp
Outdated
const std::string& target, | ||
const mp::id_mappings& gid_mappings, | ||
const mp::id_mappings& uid_mappings) | ||
: running{true}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same intuition, but I believe this needs to be alive right after construction, so that the watchdog doesn't quit before the thread starts.
To avoid confusion, one alternative would be to have an enum to distinguish the running state, instead of a bool. Something like "unstarted, running, stopped". Then in the watchdog condition, look for stopped. The logic would be the same, but it would help readers and future devs not move this and introduce a bug. WDYT?
: session{ssh_new(), ssh_free}, mut{} | ||
{ | ||
if (session == nullptr) | ||
throw mp::SSHException("could not allocate ssh session"); | ||
|
||
const long timeout_secs = std::chrono::duration_cast<std::chrono::seconds>(timeout).count(); | ||
const long timeout_secs = std::numeric_limits<long>::max(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't this a keep-alive timeout? A better var name might help here.
16562f3
to
3df817f
Compare
src/platform/platform_unix.cpp
Outdated
int sig = SIGUSR2; | ||
|
||
// A signal generator that triggers after `timeout` | ||
AutoJoinThread signaler([&sig_mtx, &sig_cv, &sig, &timeout, signalee = pthread_self()] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we need to replace this in house utility when std::jthread
is available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Trevor, the code looks good to me, but I would still love to see some unit tests on that make_quit_watchdog
. That stuff is quite complex and you made a nice job of it :) However, the logic is inherently tricky and error prone (now and in the future).
An option to make testing easier would be to use the Timer class, which is already tested (at least partially). Let me know what you think.
src/platform/platform_unix.cpp
Outdated
}); | ||
|
||
// wait on signals and condition | ||
int ret = SIGUSR2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this name be improved a little, please? This is not returned anywhere. I know it is used for the output of sigwait
, but I would expect ret to be reserved for something we return, not the return of a function we call. Perhaps latest_sig
or something of the sort. Feel free to come up with something better.
@ricab I can try to write unit tests. Timer won't help much since the main issue is the signals. Integration tests would be needed to properly test this too, sending SIGTERM is a bit too dangerous for a unit test. Where/How would I write an integration test? |
5a8e954
to
ada20ce
Compare
Sets the timeout to infinite since no messages for extended periods of time is expected behavior. Libssh updated to fix timeout being ignored.
Sets the pty mode explicitly to default since Libssh updated to inherit settings from
stdin
.Fixes #3745
MULTI-1528