High CPU usage and log file growing up #606
Comments
|
Try changing the sshd_config as mentioned in this issue #493. If you still have the issue then please share the sshd_config. |
|
Hi, thanks for the fast reply |
|
Config: |
|
Try commenting "AddressFamily inet" line and restart the sshd.. |
|
8224 23:48:59 183 debug2: signal() sig:2, handler:00000001 |
|
http://imgur.com/a/h2P0s (If can help, i use Comodo Firewall, but if i close it nothing changes) |
|
commenting "AddressFamily inet" line in sshd_config didn't help? |
|
Mmmh, no, nothing change (only disappeared 00201C70) |
|
@manojampalam - I was just noticing "Couldn't create pid file "./sshd.pid": Permission denied" in the first log posted in this thread. I assume this trying to create a pid file next to sshd.exe? AFAIK, Windows apps shouldn't try to save any state data next to an exe. To me preventing storage of file based, machine-wide state data next to binaries is one of the security improvements of Windows over linux because it keeps the binaries more secure from malware. Could ALL file based, machine-wide state data for ssh be pushed to %ProgramData%\openssh to follow Windows conventions - without requiring sshd_conf changes to do so? Actually examine and address the issue throughout the openssh code base? D. |
|
If need another info tell me |
|
@DarwinJS, as we discussed before, all logging would be done under logs folder under ssh binary path. This is for simplicity, easy discoverability and having flexibility to host multiple versions of OpenSSH side by side (Production Vs Evaluation version for example) |
|
@Leproide please provide us with network configuration of your machine (masking out any private info where applicable) ipconfig /all |
|
@manojampalam - Yep - sorry I forgot that conversation. I am not familiar with the model of ensuring something is owned by "Trusted Installer" unless it is explicitly under Windows Resource Protection (WRP). The ACLs for WRP protected resources actually LOCK OUT admin and system. There are also usually special AppCompat shims in place to lie to anything that tries to update resources owned by Trusted Installer. (These rules are created separately - they are not automatically enabled by the resource being owned by Trusted Installer). These last two attributes are what simultaneously [a] prevents updates to WRP resources - even by elevated setups and MSIs and [b] maintains compatibility so those setups don't' fail. It's possible that the reason for having "Trusted Installer" own a resource has broadened since WRP was introduced in Windows 7 - if so I'd be interested in a pointer to the details! |
netstat -anop TCPipconfig /all |
|
@DarwinJS, clarified my previous response, I meant to imply that Logs folder will be created with appropriate permissions as part of the installation, just like any other system folder. |
|
@Leproide Please collect sshd and Winsock traces from the same run. Steps to collect Winsock traces
|
|
Little problem: |
|
Oops. How long did you leave Winsock tracing on? Can you try again shortening the interval? |
|
30sec i think... |
|
300mb log file in 6 second O.o |
|
Still looking. Please attach the etl file too. Did you happen to have the corresponding sshd.log ? |
|
What do you call "high CPU usage"? |
|
@C-Duv 80/90%, i7 2600k @manojampalam In italy have 0.50 upload, 300mb log file is a suicide O.o |
|
I just talked to a Winsock expert. Please follow these steps to collect some additional traces. These will unfortunately be much more verbose, so try keeping it as short as possible. Also share the corresponding sshd logs New Tracing Steps
Attach nettrace.etl |
|
report=disabled give me error, i removed this. nettrace.etl 63,5 MB |
|
Attached etl file and sshd log. |
|
I can confirm @manojampalam the referenced "AddressFamily inet" fix worked for me for this issue. THANK YOU |
|
Here are the .etl and .cab files in a single archive (no SSH logs because Win32-OpenSSH-bug_606-nettrace.zip After setting |
|
In my case AddressFamily inet not work |
|
Can you try out the attached package and see if it works (revert "AddressFamily inet" change in sshd_config)? This is with a private fix on top of March-End package. |
|
This appears to have fixed the log spam for me. sshd starts up with just a few logs: |
|
Work :D But, the problem is? |
|
Ah, this is my (orrible) update script if anyone need |
|
This is also my problem with up to 0.10 version - full 1 core load. Not sure about log file. I even don't see it. But private fix solved my problem. And now I can see log file. |
|
@Leproide do you see any other issues? Your logs seem OK to me. Otherwise, I'll include this fix in April-Mid drop. |
|
@manojampalam works like a charm |
|
Latest release. |
|
IS this with the private I provided? Please open a new issue. |
|
Tested plain new installation of v0.0.12.0 (via Chocolatey): Issue is gone, thanks. 👍 |
Issue 787 There is a bug in the Microsoft POSIX compatibility layer used to translate POSIX socket API to Windows socket API. The bug concerns the emulated function accept() (socketio_accept() in the file socketio.c), which may return an invalid socket and may lock the program in an infinite loop. A race is happening between the Windows kernel signaling a socket issue to the POSIX compatibility layer. If a connection to the ssh service is dropped before being fully handled by the POSIX compatibility layer, that layer may reach a state where the Windows kernel is aware of the dropped connection and update all the socket states of the Windows socket API. However, the POSIX compatibility layer is in the middle of the accept() function task and fails without updating the local state of the emulated POSIX socket. When the emulated accept() exits, the current socket state is not updated and the emulated select() call would carry on detecting activity (previously already detected) on the socket, triggering the same exact error in the accept() call, running then in an infinite loop. This may not happen all the time: if the Windows kernel signals the error before the compatibility POSIX layer has setup its accept() state and returned successfully, other calls such as send() and recv() will update the state of the socket and will handle the issue. However, on a loaded machine where the synchronization between the Windows socket API and the compatibility POSIX layer may be slower, the emulated accept() call may finish before being notified by the Windows kernel of a client disconnection. This may be triggered with nmap, which makes two TCP connections in a row quickly: one to detect an opened port, and a second to retrieve the ssh banner. The fix proposed is to update the emulated accept() function to modify the internal state of the compatibility POSIX layer as a regular POSIX kernel would do. I personally had this issue and this patch fixed it. Please note that we have identified other situations where it could potentially happen (in particular the socketio_setsockopt() call). But we haven't investigated this issue more deeply. Other issues such as PowerShell#414 or PowerShell#606 may be related.
|
This issue should be fixed by now. Reopen if you still see it. |
Uh oh!
There was an error while loading. Please reload this page.
OpenSSH for Windows latest version v0.0.10.0
OS details
Windows 7 Pro x64 sp1
-High CPU usage
-Log file growing up
The text was updated successfully, but these errors were encountered: