Re: Cygwin outputting message to stderr on dofork EAGAIN failure even when Python exception is caught and handled

[Dan Shelton via Cygwin]

On Mon, 17 Jun 2024 at 18:03, Dale Lobb (Sys Admin) via Cygwin
 wrote:
>
> Greetings, Nicholas;
>
> > From: Cygwin  On 
> > Behalf Of Andrey Repin via Cygwin
> > Sent: Monday, June 17, 2024 2:58 AM
> > To: Nicholas Williams ; cygwin@cygwin.com
> > Cc: Andrey Repin 
> > Subject: EXTERNAL SENDER: Re: Cygwin outputting message to stderr on dofork 
> > EAGAIN failure even when Python exception is caught and handled
> >
> > Greetings, Nicholas Williams! > We have a Python (installed and run through 
> > Cygwin) process running on > Windows Server 2022 that was very, very 
> > occasionally failing when subprocess. check_output was called: > 0 [main] 
> > python3 28481
> >
> > Greetings, Nicholas Williams!
> >
> > > We have a Python (installed and run through Cygwin) process running on
> > > Windows Server 2022 that was very, very occasionally failing when 
> > > subprocess.check_output was called:
> >
> > > 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
> > > unexpectedly, retry 0, exit code 0xC142, errno 11
> > > …
> > > subprocess.check_output(["cygpath", "-w", directory.name], 
> > > encoding="utf-8").strip()
> > > File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
> > >  <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
> > > File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
> > >  <>with Popen(*popenargs, **kwargs) as process: <>
> > > File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
> > >  <>self._execute_child(args, executable, preexec_fn, close_fds, <>
> > > File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
> > > self.pid = _posixsubprocess.fork_exec(
> > > BlockingIOError: [Errno 11] Resource temporarily unavailable
> >
> > > Setting aside for a minute the various reasons this might be happening
> > > occasionally, which we cannot solve for at this moment, the error number
> > > (EAGAIN) indicates that you should “try again.” So that’s exactly what we
> > > did. We added a try/catch to the Python code to catch the BlockingIOError
> > > and, if and only if the error number is EAGAIN, we try up to two more 
> > > times.
> > > This fixed the problem and caused the application to stop quitting. We
> > > output a warning to our log so that we don’t forget about the problem, but
> > > the warning only ever appears once, so retrying a single time seems to 
> > > help.
> >
> > > However … even though Python handles the dofork error, turns it into a
> > > Python exception, and our code catches the Python exception and handles it
> > > properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
> > > right before our warning message. This Cygwin error message shows up as 
> > > an error in our log tracking:
> >
> > > 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
> > > unexpectedly, retry 0, exit code 0xC142, errno 11
> > > 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to 
> > > EAGAIN: [the command we’re running]

Does python require fork(), or can it use posix_spawn() in this case?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin outputting message to stderr on dofork EAGAIN failure even when Python exception is caught and handled

[Nicholas Williams via Cygwin]

Andrey and Dale,

> On Jun 17, 2024, at 11:03, Dale Lobb (Sys Admin)  
> wrote:
> 
> Greetings, Nicholas;
> 
>> From: Cygwin > > On Behalf Of 
>> Andrey Repin via Cygwin
>> Sent: Monday, June 17, 2024 2:58 AM
>> To: Nicholas Williams > >; cygwin@cygwin.com 
>> 
>> Cc: Andrey Repin mailto:anrdae...@yandex.ru>>
>> Subject: EXTERNAL SENDER: Re: Cygwin outputting message to stderr on dofork 
>> EAGAIN failure even when Python exception is caught and handled
>> 
>> Greetings, Nicholas Williams! > We have a Python (installed and run through 
>> Cygwin) process running on > Windows Server 2022 that was very, very 
>> occasionally failing when subprocess. check_output was called: > 0 [main] 
>> python3 28481
>> 
>> Greetings, Nicholas Williams!
>> 
>>> We have a Python (installed and run through Cygwin) process running on
>>> Windows Server 2022 that was very, very occasionally failing when 
>>> subprocess.check_output was called:
>> 
>>> 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
>>> unexpectedly, retry 0, exit code 0xC142, errno 11
>>> …
>>>subprocess.check_output(["cygpath", "-w", directory.name], 
>>> encoding="utf-8").strip()
>>> File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
>>> <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
>>> File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
>>> <>with Popen(*popenargs, **kwargs) as process: <>
>>> File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
>>> <>self._execute_child(args, executable, preexec_fn, close_fds, <>
>>> File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
>>>self.pid = _posixsubprocess.fork_exec(
>>> BlockingIOError: [Errno 11] Resource temporarily unavailable
>> 
>>> Setting aside for a minute the various reasons this might be happening
>>> occasionally, which we cannot solve for at this moment, the error number
>>> (EAGAIN) indicates that you should “try again.” So that’s exactly what we
>>> did. We added a try/catch to the Python code to catch the BlockingIOError
>>> and, if and only if the error number is EAGAIN, we try up to two more times.
>>> This fixed the problem and caused the application to stop quitting. We
>>> output a warning to our log so that we don’t forget about the problem, but
>>> the warning only ever appears once, so retrying a single time seems to help.
>> 
>>> However … even though Python handles the dofork error, turns it into a
>>> Python exception, and our code catches the Python exception and handles it
>>> properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
>>> right before our warning message. This Cygwin error message shows up as an 
>>> error in our log tracking:
>> 
>>> 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
>>> unexpectedly, retry 0, exit code 0xC142, errno 11
>>> 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to 
>>> EAGAIN: [the command we’re running]
>> 
>>> I’m sure there could be any number of things I might be missing, but IMO,
>>> if the process calling dofork properly handles the error raised by dofork,
>>> Cygwin should not be outputting an error message to stderr.
>> 
>>> Thoughts?
>> 
>> My inexperienced and uneducated thought would be that forking code is fragile
>> and some parts of it prone to misbehavior. When an unforeseen error is
>> detected, it's better to report it sooner, than to get bitten by it later.
>> 
>> Regarding your specific issue, if you create a STC[1] (a minimally enough
>> version of your code that, say, fork a process thousands of times, which
>> reliable reproduce the issue) somebody else could run to test the cause, that
>> would be wonderful.
>> 
>> (If, however, you could find and fix the cause, that would be even more 
>> wonderful!)
>> 
> 
>  I have seen this exact issue on every Windows  2019 or 2022
> server where I have installed new versions of Cygwin since fall of 2023.
> Admittedly, that has only been 3 or 4 machines, but it sure seems like
> a pattern.  I have resisted upgrading old Cygwin installations for fear
> that they also would start to exhibit this fork problem.
> 
> https://cygwin.com/pipermail/cygwin/2023-September/254417.html
> 
>  The only thing I have found that decreases the frequency of the
> errors is to increase the amount of RAM assigned to the machine.
> It does not eliminate the issue.  I've tried a ton of different
> options with re-basing the Cygwin executables, to no avail.
> 
> 
> Best Regards,
> 
> Dale

To be clear, the problem I’m reporting *IS NOT* the fork failure. Sure, there 
might be a bug there, or it might just be that we have a resource exhaustion 
problem that we haven’t been able to identify yet. We’ll figure that out 
eventually; for now, we have successfully worked around the problem by retrying.

The problem

cygwin runs three instances of rsync.exe at the same time

[asdffdsa6132 via Cygwin]

hello, thanks, first time poster, sorry if i mis-posted.

when in run rsync.exe, in task manager, i see three instances running at the 
same time.
in five years, my backup script runs native windows apps such as rclone.exe, 
restic.exe, fastcopy.exe, 7z.exe and never had this happen.

now, i added rsync.exe via cygwin to the script and can see three instances at 
the same time???
thanks much for cygwin, david

tasklist /fi "imagename eq rsync.exe"
Image Name                     PID Session Name        Session#    Mem Usage
=   === 
rsync.exe                    26804 Console                    1      9,132 K
rsync.exe                    16744 Console                    1      8,204 K
rsync.exe                     7796 Console                    1      7,228 K

---
contents of cygcheck.out

Cygwin Configuration Diagnostics
Current System Time: Tue Jun 18 10:45:34 2024

Windows 11 Professional Ver 10.0 Build 22631 

Path:   C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\
C:\Program Files\Intel\WiFi\bin\
C:\Program Files\Common Files\Intel\WirelessCommon\
D:\Program Files\Microsoft VS Code\bin
D:\data\l\aws\awss3cli\
C:\Program Files\WireGuard\
C:\Program Files\Mullvad VPN\resources
C:\Program Files\Tailscale\
C:\Program Files (x86)\Bitvise SSH Client
d:\Program Files\Git\cmd
C:\Program Files\PowerShell\7\
C:\Users\user01\AppData\Local\Microsoft\WindowsApps
d:\Program Files\JetBrains\PyCharm 2023.2.1\bin
D:\data\c\nmap

Output from D:\data\l\cygwin\install\bin\id.exe
UID: 197609(user01)
GID: 197121(None)
197121(None)
114(Local account and member of Administrators group)
197616(docker-users)
197612(Windows Admin Center CredSSP Administrators)
544(Administrators)
580(Remote Management Users)
545(Users)
4(INTERACTIVE)
66049(CONSOLE LOGON)
11(Authenticated Users)
15(This Organization)
113(Local account)
4095(CurrentSession)
66048(LOCAL)
262154(NTLM Authentication)
405504(High Mandatory Level)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS


ALLUSERSPROFILE = 'C:\ProgramData'
APPDATA = 'C:\Users\user01\AppData\Roaming'
CommonProgramFiles = 'C:\Program Files\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
CommonProgramW6432 = 'C:\Program Files\Common Files'
COMPUTERNAME = 'EN10'
ComSpec = 'C:\WINDOWS\system32\cmd.exe'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
HOMEDRIVE = 'C:'
HOMEPATH = '\Users\user01'
LOCALAPPDATA = 'C:\Users\user01\AppData\Local'
LOGONSERVER = '\\EN10'
NUMBER_OF_PROCESSORS = '8'
OneDrive = 'C:\Users\user01\OneDrive'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
POWERSHELL_DISTRIBUTION_CHANNEL = 'MSI:Windows 10 Pro'
PROCESSOR_ARCHITECTURE = 'AMD64'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 142 Stepping 10, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '8e0a'
ProgramData = 'C:\ProgramData'
ProgramFiles = 'C:\Program Files'
ProgramFiles(x86) = 'C:\Program Files (x86)'
ProgramW6432 = 'C:\Program Files'
PROMPT = '$P$G'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;C:\Program
 Files\Veeam\Backup and Replication\Console\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\ActiveDirectory\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\Exchange\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\Oracle\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\SharePoint\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\SQL\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\Teams\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\PostgreSQL\;C:\Program Files\Veeam\Backup and 
Replication\Explorers\SapHana\'
PUBLIC = 'C:\Users\Public'
PyCharm = 'd:\Program Files\JetBrains\PyCharm 2023.2.1\bin;'
SystemDrive = 'C:'
SystemRoot = 'C:\WINDOWS'
TEMP = 'C:\Users\user01\AppData\Local\Temp'
TMP = 'C:\Users\user01\AppData\Local\Temp'
USERDOMAIN = 'EN10'
USERDOMAIN_ROAMINGPROFILE = 'EN10'
USERNAME = 'user01'
USERPROFILE = 'C:\Users\user01'
windir = 'C:\WINDOWS'
ZES_ENABLE_SYSMAN = '1'
__COMPAT_LAYER = 'Installer'

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\D:\data\c'
  1520f07188762611 = '\??\D:\data\l\cygwin\install'
HKEY_CURRENT_USER\Software\Cygwin\setup
  (default) = 'D:\data\l\cygwin\install'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:\Program Files\SSHFS-Win'
  a426c3681297c302 = '\??\D:\data\c\ssh\clients\cygwin\install'
  4544074e7780648d = '\??\D:\data\c'
  1520f07188762611 = '\??\D:\data\l\cygwin\install'
  94b9e479e6

Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

[christianon39--- via Cygwin]

Hi, I am trying to build wlroots, but get this error in meson logs:
Command line: `cc 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c 
-D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1
stderr:
In file included from 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c:2:
/usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in a 
function); did you mean 'FD_CLOEXEC'?
   17 |   SFD_CLOEXEC = O_CLOEXEC,
  |  ^
  |  FD_CLOEXEC
---
Header "sys/signalfd.h" has symbol "SFD_CLOEXEC" : NO

subprojects/wayland-1.20.0/meson.build:83:3: ERROR: Problem encountered: 
SFD_CLOEXEC is needed to compile Wayland libraries

 Is there any solution for this? Or is it a bug that needs to be fixed?
I am using Windows 10 Version 22H2 Build: 19045.3448.
CPU: Ryzen 5 2600
GPU: Nvidia RTX 2070
RAM: 32GB

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

[christianon39--- via Cygwin]

This is a test file I ran so that I didnt need to run the build every time for 
wlroots. Compiled to exe file with "gcc -o checko test.c". Needs to have a file 
just called testfile to work

Fra: christiano...@outlook.com 
Sendt: tirsdag 18. juni 2024 17:07
Til: cygwin@cygwin.com 
Emne: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in 
a function); did you mean 'FD_CLOEXEC'?"

Hi, I am trying to build wlroots, but get this error in meson logs:
Command line: `cc 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c 
-D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1
stderr:
In file included from 
/home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c:2:
/usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in a 
function); did you mean 'FD_CLOEXEC'?
   17 |   SFD_CLOEXEC = O_CLOEXEC,
  |  ^
  |  FD_CLOEXEC
---
Header "sys/signalfd.h" has symbol "SFD_CLOEXEC" : NO

subprojects/wayland-1.20.0/meson.build:83:3: ERROR: Problem encountered: 
SFD_CLOEXEC is needed to compile Wayland libraries

 Is there any solution for this? Or is it a bug that needs to be fixed?
I am using Windows 10 Version 22H2 Build: 19045.3448.
CPU: Ryzen 5 2600
GPU: Nvidia RTX 2070
RAM: 32GB
#include 
#include 

int main() {
int fd = open("testfile", O_RDONLY);
if (fd == -1) {
perror("open");
return 1;
}

int flags = fcntl(fd, F_GETFD);
if (flags == -1) {
perror("fcntl");
return 1;
}

if (flags & FD_CLOEXEC) {
printf("O_CLOEXEC is supported.\n");
} else {
printf("O_CLOEXEC is not supported.\n");
}

close(fd);
return 0;
}

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin outputting message to stderr on dofork EAGAIN failure even when Python exception is caught and handled

[Nicholas Williams via Cygwin]

Dan,

> On Jun 18, 2024, at 09:44, Dan Shelton via Cygwin  wrote:
> 
> On Mon, 17 Jun 2024 at 18:03, Dale Lobb (Sys Admin) via Cygwin
>  wrote:
>> 
>> Greetings, Nicholas;
>> 
>>> From: Cygwin  On 
>>> Behalf Of Andrey Repin via Cygwin
>>> Sent: Monday, June 17, 2024 2:58 AM
>>> To: Nicholas Williams ; cygwin@cygwin.com
>>> Cc: Andrey Repin 
>>> Subject: EXTERNAL SENDER: Re: Cygwin outputting message to stderr on dofork 
>>> EAGAIN failure even when Python exception is caught and handled
>>> 
>>> Greetings, Nicholas Williams! > We have a Python (installed and run through 
>>> Cygwin) process running on > Windows Server 2022 that was very, very 
>>> occasionally failing when subprocess. check_output was called: > 0 [main] 
>>> python3 28481
>>> 
>>> Greetings, Nicholas Williams!
>>> 
 We have a Python (installed and run through Cygwin) process running on
 Windows Server 2022 that was very, very occasionally failing when 
 subprocess.check_output was called:
>>> 
 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
 unexpectedly, retry 0, exit code 0xC142, errno 11
 …
subprocess.check_output(["cygpath", "-w", directory.name], 
 encoding="utf-8").strip()
 File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
 <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
 File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
 <>with Popen(*popenargs, **kwargs) as process: <>
 File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
 <>self._execute_child(args, executable, preexec_fn, close_fds, <>
 File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
self.pid = _posixsubprocess.fork_exec(
 BlockingIOError: [Errno 11] Resource temporarily unavailable
>>> 
 Setting aside for a minute the various reasons this might be happening
 occasionally, which we cannot solve for at this moment, the error number
 (EAGAIN) indicates that you should “try again.” So that’s exactly what we
 did. We added a try/catch to the Python code to catch the BlockingIOError
 and, if and only if the error number is EAGAIN, we try up to two more 
 times.
 This fixed the problem and caused the application to stop quitting. We
 output a warning to our log so that we don’t forget about the problem, but
 the warning only ever appears once, so retrying a single time seems to 
 help.
>>> 
 However … even though Python handles the dofork error, turns it into a
 Python exception, and our code catches the Python exception and handles it
 properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
 right before our warning message. This Cygwin error message shows up as an 
 error in our log tracking:
>>> 
 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
 unexpectedly, retry 0, exit code 0xC142, errno 11
 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to 
 EAGAIN: [the command we’re running]
> 
> Does python require fork(), or can it use posix_spawn() in this case?

I imagine this would be question for the CPython development team. While I have 
a basic understanding of C programming in Python (for the purposes of writing 
extensions), I do not know why subprocess.Popen is written in this way, and I 
do not know enough to question their choice here. It uses fork, and for now I 
have to live with that.

Thanks,

Nick


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Unknown Charge: Requesting Further Details

[info--- via Cygwin]

Hi there,

I trust this message finds you well. I am writing to inquire about an unknown 
debit that has appeared on my bank account from your store.

I do not have a record of making a order from your store in the recent past, 
and I am troubled that this may be an mistake. I would be grateful for it if 
you could give me with details regarding this charge.

Please let me know the following:
The details of the order associated with this charge (e.g., products 
bought, order's number).
Any measures I need to take if this charge was made in mistake or if it is 
an unauthorized transaction.

Thank you for your quick assistance to this matter. I look forward to your 
reply.

Best wishes,
Jessica Berge

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin runs three instances of rsync.exe at the same time

[Sam Edge via Cygwin]

On 18/06/2024 16:03, asdffdsa6132 via Cygwin wrote:

hello, thanks, first time poster, sorry if i mis-posted.

when in run rsync.exe, in task manager, i see three instances running at the 
same time.
in five years, my backup script runs native windows apps such as rclone.exe, 
restic.exe, fastcopy.exe, 7z.exe and never had this happen.

now, i added rsync.exe via cygwin to the script and can see three instances at 
the same time???
thanks much for cygwin, david

tasklist /fi "imagename eq rsync.exe"
Image Name                     PID Session Name        Session#    Mem Usage
=   === 
rsync.exe                    26804 Console                    1      9,132 K
rsync.exe                    16744 Console                    1      8,204 K
rsync.exe                     7796 Console                    1      7,228 K



This is how rsync works. The executable forked from the command line
runs up two communicating child processes to handle the 'from' and 'to'
ends of the transfer.

If you are using rsync across the network, one of the children is
created on the other computer, either via an rsync daemon process or via
remote shell, usually ssh.

The documentation for rsync explains this.

--
Sam Edge


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin runs three instances of rsync.exe at the same time

[Sam Edge via Cygwin]

On 19/06/2024 07:09, Sam Edge via Cygwin wrote:


This is how rsync works. The executable forked from the command line
runs up two communicating child processes to handle the 'from' and 'to'
ends of the transfer.


I forgot to say, this is how rsync works on any platform such as Linux
or OS X or whatever, not just Cygwin.

https://download.samba.org/pub/rsync/rsync.1

--
Sam Edge


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple