Does sftp become unusable after the first command?

[cheako]

I get this on line 198:

cheako@mx3:~/src/gitlab/ayas_xilrieth$ cargo build -r && distrobox-host-exec sudo target/release/ayas_xilrieth 3053
    Finished `release` profile [optimized] target(s) in 0.02s
ERROR: ld.so: object 'libdontdie.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Error: BackgroundTaskFailure("read/flush task failed")

https://gitlab.com/cheako/ayas-xilrieth/-/blob/openssh001/src/main.rs#L116

strace.log

[NobodyXu]

ERROR: ld.so: object 'libdontdie.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

This looks like something wrong with your environment, particularly LD_PRELOAD

[cheako]

That is sudo.... for obvious reasons it blocks preload. As much as it hurts, that lib is the official way of enabling tcp options.... it fixes Starlink internet. Otherwise, sat handovers stall downloads. I wish more ppl knew.

[NobodyXu]

It might be that the ssh process can't run due to this.

You would need to enable openssh/native-mux and use the corresponding API to avoid ssh process creation

[cheako]

The failure is on the second cmd, after listing a dir.

[NobodyXu]

The failure is on the second cmd, after listing a dir.

No it shouldn't happen, I recommend turning on tracing feature of openssh-sftp-client and openssh, then use tracing-subscriber to log all events, it might include the cause of error

[cheako]

I switched to russh and my project is done. I guess what I was saying, not that libdontdie wasn't the cause, but that the message had a known benign explanation. As well as there is proof the ssh process is running.

I'm glad you didn't first assume it is a simple coding error on my part, but I'm not so grandiose.

The task seems simple, I only didn't use bash because I wanted to know what it meant to write scripts in rust.
As root, login with a users agent, read a dir, (see edit), stream a local command into a remote one, then write a file.
Edit: the part that failed was creating a directory, I forgot about that.

https://gitlab.com/cheako/ayas-xilrieth/-/blob/e6b9f588b1912a42f0a702f1891e9cc73636d634/src/main.rs

[NobodyXu]

BackgroundTaskFailure is returns by openssh-sftp-client when the background task exits unexpectedly.

In order to get the exact error from the background task, you would need to call Sftp::close which actually waits for the task.

There's also feature openssh-sftp-client/tracing that will provide error logging.

[cheako]

I'm think you are 0/3... I can't imagine you'd need more logs than the strace.

At line 1985, openssh does a little trick. I guess it's to get the local address/perhaps to remove ipv4, I never would have thought to do it that way. Cool, but not the point.
Line 1997 is where libdontdie inserts itself, looks good to me.
Line 2219 is where pid 740805 becomes 740807, so know that even though there is not an exec.*ssh for this pid it is our ssh client.
skipping ahead line 3521 is where openssh get's a signal to exit and closes safely informing the remote host.
That signal comes from 740809 on line 3510.
In response to the write from openssh on line 3502.
See line 3483 dejavue, I thought for a second my scroll where wasn't working.
That comes from 3128 pid 740786.
This looks like something we should be paying attention too 3039. I'm just assuming that if I looked from there down things would connect naturally.
That comes from 2992 pid 740786 ayas_xilrieth our parent.
2942 [pid 740807] we have a directory coming over.
And just after we have the main thread killing sftp, I assume from the partial cmdlines. One would guess something that wasn't supposed too went out of scope.

[NobodyXu]

I'm think you are 0/3... I can't imagine you'd need more logs than the strace.

strace can't show you what's happening inside the application, especially when network protocols, parsing and tokio tasks are involved here, the process analysis you put up just aren't informative.

strace only shows syscalls, not the state of the application, you would have to guess it which is terrible, using log from openssh-sftp-client would give more information

There could be a bug in openssh-sftp-client or something else but strace is totally not helpful.

I strongly recommend you to

• call Sftp::close
• enable openssh-sftp-client/tracing
• use tracing_subscriber to register a logging implementation, with DEBUG log level (you can make it a cmdline arg)

Until you do that I'm afraid I can't offer much help with strace @cheako

[cheako]

fs::Fs needs Sftp and Sftp needs both Child(ren). The children correctly need the Session, so add the other two dependencies(phantomdata??).

I put this in main() scope and that worked as expected. I guess you could say trying to use the return of the function for passing data is the issue.

    let mut session_out = Option::<Session>::None;
    let session = &mut session_out;
    let mut child_out = Option::<Child<&Session>>::None;
    let child = &mut child_out;
    let mut sftp_out = Option::<Sftp>::None;
    let sftp = &mut sftp_out;
    let mut fs_out = Option::<fs::Fs>::None;
    let fs = &mut fs_out;

Here is the commit: https://gitlab.com/cheako/ayas-xilrieth/-/commit/7a15125111d098578aa851d9adde70c1a7e8bf8f

[NobodyXu]

There's a Sftp::from_session function that avoids all the manual openssh process creation, if you havs openssh-sftp-client/openssh feature enabled

[NobodyXu]

@cheako Also I recommend using native-mux feature of openssh, it's much better than process-mux

[cheako]

Thanks, but I'm using russh now. https://gitlab.com/cheako/ayas-xilrieth/-/blob/russh002/src/main.rs#L67

[NobodyXu]

I would appreciate PR to add russh as a feature to this openssh!

I was thinking about it but never got time...