Sorry for forgetting Cc the mailing list.
>> What happens, if you open a shell on your remote vm01 host, and raise >> the command >> >> # \readlink --canonicalize-missing /usr/src/kernels/5.3.7-301.fc31.x86_64 It prints out "/usr/src/kernels/5.3.7-301.fc31.x86_64”. >> I haven't seen such race conflicts so far. In general, Tramp shall be >> able to handle concurrent (asynchronous) processes. I think Tramp use a “*tramp/method host*” buffer to receive the output from the remote side. What would happen if multiple asynchronous process (in my case, the compile process and the readlink process) send output to this buffer at the same time? Is there some "mutex"-like thing to prevent this? If you will, could you elaborate a little about how Tramp handles concurrent access to the same connection? >> But if there is much >> output from compilation, it could happen. This is aligned with what I can observed: this issue happens only when I compile a kernel module (in my case) where minor error can cause a lot error report with a lot of header file links. >> >> You could try to set tramp-verbose to 6, and rerun your test. Maybe we >> see something in the traces, but it would be hard if there are many data. >> I tried, unfortunately the message only shows the following: Tramp: Opening connection for vm01 using ssh... Tramp: Sending command ‘exec ssh -q -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none vm01’ Tramp: Waiting for prompts from remote shell...done Tramp: Found remote shell prompt on ‘vm01’ Tramp: Opening connection for vm01 using ssh...done Entering debugger... "Entering debugger..." is print after I observed hang and "pkill -SIGUSR2 Emacs”. For me, this bug is so hard to debug since they are async and concurrent:( Do you have some advice for me to further look into this? Best regards, Fan
