PROTECTED]>
> Sent: Monday, December 23, 2002 10:59 AM
> Subject: Re: Cygrunsrv problem starting service created with --user
>
>
> > I am doing something similar and have been following this thread because I
> > have run into the same problem...
> >
> > my qu
, which
I found easy enough. Doh!
~ Terry
757 581-5981
AIM/Yahoo: lv2bounce
- Original Message -
From: "Igor Pechtchanski" <[EMAIL PROTECTED]>
To: "Terry" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 23, 2002 11:30 AM
Subject:
Chris Roehrig wrote:
I have a network of Windows, Linux and Mac machines and I use rsync to
synchronize various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only when
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cygwin r
Here's my test in a nutshell:
# ON WINDOWS: install Cygwin and enable cygsshd
ssh-host-config -y
# set up authorized keys, etc to make things easier
# LINUX: Create a 2GB random file on Linux:
dd if=/dev/urandom of=/tmp/bigfile.bin bs=1M count=2000
# WINDOWS: rsync "pull"
On Tue, Aug 24, 2021, 09:50 Chris Roehrig wrote:
> I have a network of Windows, Linux and Mac machines and I use rsync to
> synchronize various directories between them.
>
> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only
> when the remote endpoint is Cygwin rsync over
Here's the other direction with rsync also in --daemon mode:
# ON WINDOWS (from a mintty terminal):
dd if=/dev/urandom of=/tmp/bigfile.bin bs=1M count=2000 # create 2GB
file
printf "[TMP]\npath = /tmp\n" > /etc/rsyncd.conf
# create rsyncd.conf
NightStrike via Cygwin wrote:
Older versions of windows had a setting to optimize the OS for either
background services or foreground applications. One of the things this did
was throttle network usage. I don't know if windows 10 has the same setting
though.
Yes, it does. Getting to it is a pa
On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:
> I have a network of Windows, Linux and Mac machines and I use rsync to
> synchronize various directories between them.
>
> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only
> when the remote endpoint is Cygwin rsy
It was set to "Programs".Changing it to "Background services" didn't make
a difference.
TCPOptimizer can adjust 2 registry entries that I think are related to that
Windows Setting:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Multimedia\SystemProfile]
"NetworkT
The FILE_FLAG_OVERLAPPED avenue looks promising. I get exactly the same
results as you using 'scp': 4MB/s in either direction (with either remote
endpoint.)
I guess the next step is to install a build environment and build rsync and
sshd ...
On Wed Aug 25 2021, at 4:18 AM, Takashi Ya
On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:
I have a network of Windows, Linux and Mac machines and I use rsync to
synchronize various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s
On Wed Aug 25 2021, at 10:52 AM, Ken Brown via Cygwin wrote:
> A couple years ago I had an idea for changing the pipe implementation to
> avoid overlapped I/O:
>
> https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
> https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
>
It looks like there was a previous (2013) patch and attempt to add a
pipe_nooverlap CYGWIN option that was rejected by the maintainers:
https://stackoverflow.com/questions/10385424/good-alternatives-to-cygwin-cygwin-doesnt-support-natively-support-win32-app
Is this something that can be revisite
On 25.08.21 19:52, Ken Brown via Cygwin wrote:
A couple years ago I had an idea for changing the pipe implementation to avoid
overlapped I/O:
https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
I never followed up
On Wed, 25 Aug 2021 13:52:19 -0400
Ken Brown wrote:
> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
> > On Tue, 24 Aug 2021 12:49:52 -0700
> > Chris Roehrig wrote:
> >> I have a network of Windows, Linux and Mac machines and I use rsync to
> >> synchronize various directories between them.
On 8/25/2021 2:18 PM, Chris Roehrig wrote:
On Wed Aug 25 2021, at 10:52 AM, Ken Brown via Cygwin wrote:
A couple years ago I had an idea for changing the pipe implementation to avoid
overlapped I/O:
https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
https://cygwin.com/pipermai
On 8/25/2021 4:33 PM, Mario Emmenlauer wrote:
On 25.08.21 19:52, Ken Brown via Cygwin wrote:
A couple years ago I had an idea for changing the pipe implementation to avoid
overlapped I/O:
https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
https://cygwin.com/pipermail/cygwin-p
On 8/25/2021 5:29 PM, Takashi Yano wrote:
On Wed, 25 Aug 2021 13:52:19 -0400
Ken Brown wrote:
On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:
I have a network of Windows, Linux and Mac machines and I use rsync to
synchronize various
On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
On 8/25/2021 5:29 PM, Takashi Yano wrote:
On Wed, 25 Aug 2021 13:52:19 -0400
Ken Brown wrote:
On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:
I have a network of Windows, Linux and M
On Thu, 26 Aug 2021 18:18:29 -0400
Ken Brown wrote:
> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> > On 8/25/2021 5:29 PM, Takashi Yano wrote:
> >> On Wed, 25 Aug 2021 13:52:19 -0400
> >> Ken Brown wrote:
> >>> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
> On Tue, 24 Aug 2021
On 8/27/2021 7:24 AM, Takashi Yano wrote:
On Thu, 26 Aug 2021 18:18:29 -0400
Ken Brown wrote:
On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
[...]
In case you want to try out my proposed change, I've just rebased the patches to
the current master and pushed them to a new topic/pipe branch.
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
> On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > On Thu, 26 Aug 2021 18:18:29 -0400
> > Ken Brown wrote:
> >> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> [...]
> >> In case you want to try out my proposed change, I've just rebased the
>
On Sat, 28 Aug 2021 02:21:11 +0900
Takashi Yano wrote:
> On Fri, 27 Aug 2021 12:00:50 -0400
> Ken Brown wrote:
>
> > On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > > On Thu, 26 Aug 2021 18:18:29 -0400
> > > Ken Brown wrote:
> > >> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> > [...]
> > >>
On Sat, 28 Aug 2021 11:00:24 +0900
Takashi Yano wrote:
> On Sat, 28 Aug 2021 02:21:11 +0900
> Takashi Yano wrote:
>
> > On Fri, 27 Aug 2021 12:00:50 -0400
> > Ken Brown wrote:
> >
> > > On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > > > On Thu, 26 Aug 2021 18:18:29 -0400
> > > > Ken Brown wrote:
>
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> On Fri, 27 Aug 2021 12:00:50 -0400
> Ken Brown wrote:
> > Two years ago I thought I needed nt_create to avoid problems when calling
> > set_pipe_non_blocking. Are you saying that's not an issue? Is
> > set_pipe_non_blocking unnecessary? Is that
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > On Fri, 27 Aug 2021 12:00:50 -0400
> > Ken Brown wrote:
> > > Two years ago I thought I needed nt_create to avoid problems when calling
> > > set_pipe_non_blocking. Are you saying that
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> On Sat, 28 Aug 2021 10:43:27 +0200
> Corinna Vinschen wrote:
> > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > Ken Brown wrote:
> > > > Two years ago I thought I needed nt_create to avoid problems whe
On 8/28/2021 4:43 AM, Corinna Vinschen via Cygwin wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I needed nt_create to avoid problems when calling
set_pipe_non_blocking. Are you saying that's not an issue? Is
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
> On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 10:43:27 +0200
> > Corinna Vinschen wrote:
> > > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > > Ken Brown wrote:
>
On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00
Hi Ken,
On Sat, 28 Aug 2021 16:55:52 -0400
Ken Brown wrote:
> On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 13:58:08 +0200
> > Corinna Vinschen wrote:
> >> On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> >>> On Sat, 28 Aug 2021 10:43:27 +0200
> >>> Corinna Vinsche
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
> On Sat, 28 Aug 2021 10:43:27 +0200
> Corinna Vinschen wrote:
> > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > Ken Brown wrote:
> > > > Two years ago I thought I needed nt_create to avoid probl
On Aug 29 00:43, Takashi Yano via Cygwin wrote:
> On Sat, 28 Aug 2021 13:58:08 +0200
> Corinna Vinschen wrote:
> > On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> > > On Sat, 28 Aug 2021 10:43:27 +0200
> > > Corinna Vinschen wrote:
> > > > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > > >
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I
I'd be happy to test it out if you can give me some commands to git it and
build it to replace my existing stock Cygwin installation.
(Or it is just the cygwin.dll I'd need to replace?)
My daily backup scripts use a lot of pipes and named pipes.
-- Chris
On Sun Aug 29 2021, at 8:57 AM, Ken Br
On Sun, 29 Aug 2021 11:57:04 -0400
Ken Brown wrote:
> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 18:41:02 +0900
> > Takashi Yano wrote:
> >> On Sat, 28 Aug 2021 10:43:27 +0200
> >> Corinna Vinschen wrote:
> >>> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
>
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I
On 8/29/2021 3:37 PM, Takashi Yano wrote:
On Sun, 29 Aug 2021 11:57:04 -0400
Ken Brown wrote:
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano vi
On 8/29/2021 3:24 PM, Chris Roehrig wrote:
I'd be happy to test it out if you can give me some commands to git it and
build it to replace my existing stock Cygwin installation.
(Or it is just the cygwin.dll I'd need to replace?)
My daily backup scripts use a lot of pipes and named pipes.
It's
On 8/29/2021 4:41 AM, Takashi Yano wrote:
Hi Ken,
On Sat, 28 Aug 2021 16:55:52 -0400
Ken Brown wrote:
On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 10:43:27
On Sun, 29 Aug 2021 17:04:56 -0400
Ken Brown wrote:
> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 18:41:02 +0900
> > Takashi Yano wrote:
> >> On Sat, 28 Aug 2021 10:43:27 +0200
> >> Corinna Vinschen wrote:
> >>> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
>
On Mon, 30 Aug 2021 09:13:14 +0900
Takashi Yano wrote:
> On Sun, 29 Aug 2021 17:04:56 -0400
> Ken Brown wrote:
> > On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > > On Sat, 28 Aug 2021 18:41:02 +0900
> > > Takashi Yano wrote:
> > >> On Sat, 28 Aug 2021 10:43:27 +0200
> > >> Corinna Vinsche
On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
On Mon, 30 Aug 2021 09:13:14 +0900
Takashi Yano wrote:
On Sun, 29 Aug 2021 17:04:56 -0400
Ken Brown wrote:
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43
On Sun, 29 Aug 2021 22:15:29 -0400
Ken Brown wrote:
> On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
> > On Mon, 30 Aug 2021 09:13:14 +0900
> > Takashi Yano wrote:
> >> On Sun, 29 Aug 2021 17:04:56 -0400
> >> Ken Brown wrote:
> >>> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> O
I got it to build and tried out the topic/pipe branch (checked out on Monday
around 4:30pm PDT):
1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec.
2. I get the following error from procps: procps:ps/output.c:2195: please
report this bug
(I also get this using the main
On 8/30/2021 7:58 PM, Chris Roehrig wrote:
I got it to build and tried out the topic/pipe branch (checked out on Monday
around 4:30pm PDT):
1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec.
2. I get the following error from procps: procps:ps/output.c:2195: please
re
Thanks, I did some more tests:
scp also shows no improvement with topic/pipe.I tried running
cygsshd with CYGWIN=pipe_byte as well as empty (in the registry
HKLM/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/Environment/), using
net stop cygsshd + net start cygsshd to restart
I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get
100MB/s transfers using both rsync and scp (without pipe_byte).
(It turns out last time I forgot 'make install' -- Doh!)
I still get the procps error however.
On Tue Aug 31 2021, at 12:53 PM, Chris Roehrig wrote:
I've found you must also copy the matching cygwin-console-helper.exe
for everything to work correctly!
On 2021-08-31 14:23, Chris Roehrig wrote:
I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get
100MB/s transfers using both rsync and scp (without pipe_byte).
(It t
I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
the stock procps package is incompatibility with the current master branch.
(However, I built it against the stock /usr/include, not the current branch...)
I first needed to 'make /proc/libprocps.la', and there was an
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
the stock procps package is incompatibility with the current master branch.
Maybe, but it could also be a Cygwin bug. I'll do a bisection of the Cygwin
sources to see if I c
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
> On 9/1/2021 5:11 PM, Chris Roehrig wrote:
>> I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
>> the stock procps package is incompatible with the current master branch.
>
> Maybe, but it could also be a C
On 9/2/2021 3:03 PM, Chris Roehrig wrote:
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
the stock procps package is incompatible with the current master branch.
[resent, this time with the ML in To]
On Sep 2 12:03, Chris Roehrig wrote:
>
> On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
> > On 9/1/2021 5:11 PM, Chris Roehrig wrote:
> >> I rebuild procps 3.3.17.29-2480 from source and it appears to work, so
> >> maybe the stock procps packag
On Fri Sep 3 2021, at 12:55 PM, Corinna Vinschen
wrote:
> [resent, this time with the ML in To]
>
> On Sep 2 12:03, Chris Roehrig wrote:
>>
>> On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin
>> wrote:
>>> On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 fro
Am 03.09.2021 um 22:59 schrieb Chris Roehrig:
I got procps working I think (both with and without the revert).
That likely wasn't what Corinna wanted to know, though.
Please re-install the procps-ng, cygwin and cygwin-devel packages from
setup (and revert any other alterations you may have ma
On 2021-09-03 14:59, Chris Roehrig wrote:
On Fri Sep 3 2021, at 12:55 PM, Corinna Vinschen wrote:
On Sep 2 12:03, Chris Roehrig wrote:
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it appea
04.09.2021 18:45, Brian Inglis:
[...]
then to install all binary packages for dogfooding:
Would you please stop telling folks to do things that potentially breaks
their systems?
There are quite a few more steps to take if you want to emulate what
setup does. Then again you cannot do that o
On 2021-09-05 02:18, Achim Gratz wrote:
04.09.2021 18:45, Brian Inglis:
[...]
then to install all binary packages for dogfooding:
Would you please stop telling folks to do things that potentially breaks
their systems?
There are quite a few more steps to take if you want to emulate what
set
05.09.2021 17:11, Brian Inglis:
The suggestion was intended as a tip to ensure *complete* locally
rebuilt package contents are installed,
Setup has its "from_cwd" installation mode for precisely that reason:
installing a local package without the need to create a full install
hierarchy and s
I've been following his thread with interest both here and on the Cygwin
developers list. I, too rsync between Cygwin and Linux machines.
Lots of good debate showing the genius of the folks that support the cygwin
infrastructure.
Looks like the lively discussion on both lists has stopped. What
On 9/16/2021 6:00 PM, Keith Christian via Cygwin wrote:
I've been following his thread with interest both here and on the Cygwin
developers list. I, too rsync between Cygwin and Linux machines.
Lots of good debate showing the genius of the folks that support the cygwin
infrastructure.
Looks li
Ken,
Thank you for the reply, this is great news!
Looking forward to speedier rsyncs with Cygwin.
Keith
On Thu, Sep 16, 2021, 16:49 Ken Brown via Cygwin wrote:
> On 9/16/2021 6:00 PM, Keith Christian via Cygwin wrote:
> > I've been following his thread with interest both here a
On Nov 12 17:44, Christian Franke wrote:
> Hi,
>
> if the exec in cygrunsrv fails or the command exits to early, cygrunsrv
> will hang forever.
> The service can no longer be controlled until cygrunsrv has been kill(-9)ed.
> Auto restart of service does not work in this case.
>
>
> Steps to rep
Corinna Vinschen wrote:
[...]
Thanks for this report and the simple testcases. The description
is very helpful. I just don't really like the idea to leave the
service_main function through _exit.
Agree. But this is IMO the only way to let SCM automatically restart a
failed service if desi
On Nov 13 15:46, Christian Franke wrote:
> Corinna Vinschen wrote:
> >Thanks for this report and the simple testcases. The description
> >is very helpful. I just don't really like the idea to leave the
> >service_main function through _exit.
>
> Agree. But this is IMO the only way to let SCM aut
You have to find the cygrunsrv process associated with that service and
kill it using Task Manager or whatever. I have not found a way of
matching them up, so when I am having problems with one of my Cygwin
services, I shut down all other Cygwin services so I don't kill the
wrong one.
--
lhicks a
Chris Wilson <[EMAIL PROTECTED]> writes:
> When I run random Windows applications, Cygrunsrv.exe starts
> consuming almost all the CPU.
Yes, I saw the same thing last night, after having updated my Cygwin
installation over the weekend. In my case I was toying around with
Exact Audio Copy, with ba
Yep, it looks like CSRSS.EXE is taking whatever is leftover from the
Cygwin-related task.
I did _MUCH_ web surfing last night, looking for information pertaining
to the CSRSS.EXE and it looks like it's basically responsible for
handling the Win32 subsystem. I tried tweaking this and that by
a
On Sat, 2 Sep 2006, Ron Dozier wrote:
> I noted that a lot of people are having trouble getting the sshd service
> to start automatically. I think I discovered a problem.
>
> Run services.msc and selecting sshd) there is a "Path to executable"
> field that currently says :"C:\cygwin\bin\cygrunsrv
Ron Dozier wrote:
>
> I noted that a lot of people are having trouble getting the sshd service to
> start automatically.
What? The only problem is that people don't read the _Cygwin_ provided
documentation and follow it (or even find it).
> I think I discovered a problem.
>
> Run services.msc
Ron Dozier wrote
> I noted that a lot of people are having trouble getting the sshd
> service to start automatically.
I've run into the same issue with exim, sshd, and/or cron. I haven't
tried to dig for the root cause. Running rebaseall fixes the issue
(whatever it is), and that's good enough f
I finally found the problem with not being able to
start my service (kept getting: cygrunsrv: Error
starting a service: QueryServiceStatus: Win32 error
1062: The service has not been started.).
WRONG:
cygrunsrv --install rsync_daemon --user
'mynetwork\theusername' --path /usr/bin/rsync -a
"--daem
On Dec 7 13:30, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi all,
>
> I have a suggestion that cygrunsrv doesn't ask for any password with
> the option -u (and -w not provided), if the specified user is like
> "NT SERVICE\svcname", where svcname is the service being added.
>
> Otherwise, cyg
> cygrunsrv -I svcname -u "NT SERVICE\svcname" -p ''
I'm not quite sure I follow your suggestion:
-p is for path to the actual executable that implements the background process
If you meant -w '' (or as documentation suggests '-w ') then it does not work
for some reason -- cygrunsrv cannot ins
> per the bad user/pass combo, presumably).
Per MSDN,
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450%28v=vs.85%29.aspx
:
If the account name specified by the lpServiceStartName parameter is the name
of a managed service account or virtual account name, the lpPassword paramete
On Dec 7 16:49, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > per the bad user/pass combo, presumably).
>
> Per MSDN,
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450%28v=vs.85%29.aspx
> :
>
> If the account name specified by the lpServiceStartName parameter is the name
>
Just checking whether this is going to be implemented...
Thanks,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> -Original Message-
> Sent: Friday, December 07, 2012 11:50 AM
> Subject: RE: Cygrunsrv and special Windows virtual accounts "NT
> SERVICE"
>
> &
On Dec 14 16:01, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Just checking whether this is going to be implemented...
http://cygwin.com/ml/cygwin/2012-12/msg00154.html
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin
> http://cygwin.com/ml/cygwin/2012-12/msg00154.html
Thanks.
> I'm wondering if it's such a bright idea to use a NULL password based on
> a check for a certain domain. That's practically guaranteed to break
> at one point again.
I don’t think Microsoft is going to drop "NT SERVICE\" in any near
On Fri, Dec 14, 2012 at 05:06:16PM +0100, Corinna Vinschen wrote:
>On Dec 14 16:01, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> Just checking whether this is going to be implemented...
>
>http://cygwin.com/ml/cygwin/2012-12/msg00154.html
So you're working on it?
cgf
--
Problem reports:
On Dec 14 16:23, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > http://cygwin.com/ml/cygwin/2012-12/msg00154.html
>
> Thanks.
>
> > I'm wondering if it's such a bright idea to use a NULL password based on
> > a check for a certain domain. That's practically guaranteed to break
> > at one point
> what about '-w -' or a long-only option like --null-pwd?
I'd be happy with either!
Thanks,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
Greetings, Corinna Vinschen!
> Apart from the fact that NULL is a terrible password, I'd still be more
> comfortable to allow a NULL password as a user defined option on the
> command line. If not -W NULL, what about '-w -' or a long-only option
> like --null-pwd?
I'd say, the latter.
"-w -" loo
On 12/18/2012 05:57 AM, Andrey Repin wrote:
what about '-w -' or a long-only option
> like --null-pwd?
I'd say, the latter.
"-w -" looks like you are trying to read password from STDIN.
I heartily concur for two reasons:
1) '-w -' really looks like like stdin/out
2) '-' is actually a vali
On Dec 18 10:45, bartels wrote:
> On 12/18/2012 05:57 AM, Andrey Repin wrote:
> >> what about '-w -' or a long-only option
> >>> like --null-pwd?
> >I'd say, the latter.
> >"-w -" looks like you are trying to read password from STDIN.
>
> I heartily concur for two reasons:
>
> 1) '-w -' really
On 14/03/2018 01:38, Tatsuro MATSUOKA wrote:
Followingng the below
https://cygwin.com/cygwin-ug-net/using-cygserver.html
Start Cygwin shell with admin right.
$ cygserver-config
and /etc/cygserver.conf is created
execute
$ cygrunsrv -S cygserver
On Cygwin86_64
$ ps -a | grep 'cyg'
5428
> From: Marco Atzeri
> To: cygwin
> Cc:
> Date: 2018/3/14, Wed 15:28
> Subject: Re: cygrunsrv -S cygserver on Cygwin86 does not run
>
> On 14/03/2018 01:38, Tatsuro MATSUOKA wrote:
>> Followingng the below
>> https://cygwin.com/cygwin-ug-net/using-cygserver
> From: Marco Atzeri
> To: cygwin
> Cc:
> Date: 2018/3/14, Wed 15:28
> Subject: Re: cygrunsrv -S cygserver on Cygwin86 does not run
>
> On 14/03/2018 01:38, Tatsuro MATSUOKA wrote:
>> Followingng the below
>> https://cygwin.com/cygwin-ug-net/using-cygs
On 2018-03-14 22:13, Tatsuro MATSUOKA wrote:
> On 2018/3/14, Wed 15:28 Marco Atzeri wrote:
>> Is it same machine ?
>> If so the `cygrunsrv -S cygserver` is starting in both case the 64bit
>> version
>> and you can not see it as process in 32bit.
>>
>> The problem is due that the services "cygse
Tatsuro MATSUOKA writes:
> At execute Cygwin setup, kiling all cygwin process is highly recommended
> becase setpup execute autorebase.
Well, it's mandatory actually.
> kill-9-1_32_64.bat
> @echo off
> C:\cygwin\bin\cygstart --action=runas /bin/kill -9 -1
> C:\cygwin64\bin\cygstart --action=runas
- Original Message -
> From: Brian Inglis
> To: cygwin
> Cc:
> Date: 2018/3/15, Thu 14:46
> Subject: Re: cygrunsrv -S cygserver on Cygwin86 does not run
>
> On 2018-03-14 22:13, Tatsuro MATSUOKA wrote:
>> On 2018/3/14, Wed 15:28 Marco Atzeri wrote:
>>
- Original Message -
> From: Achim Gratz
> To: cygwin
> Cc:
> Date: 2018/3/16, Fri 03:06
> Subject: Re: cygrunsrv -S cygserver on Cygwin86 does not run
>
>T atsuro MATSUOKA writes:
>> At execute Cygwin setup, kiling all cygwin process is highly recommende
Tatsuro MATSUOKA writes:
> http://cygwin.wikia.com/wiki/Rebaseall
> $ cygrunsrv -E
> The above seem to be propper way to stop sevice process.
…if you need to do it from within Cygwin. If you're doing it from a CMD
or BAT file it's easier and slightly more efficient to use the Windows
tools.
Re
On Feb 6 08:43, Bill Stewart via Cygwin wrote:
> FYI:
>
> In our corporate environment we run vulnerability scans, and one of the
> most common complaints of the scanner is "unquoted service paths."
>
> To fix this "vulnerability," I use a quoted service path for cygrunsrv.exe;
> e.g.:
>
> "C:\
On Mon, Feb 6, 2023 at 1:06 PM Corinna Vinschen wrote:
Yeah, quoted paths were not handled at all. I pushed a new version
> 1.64 which contains a patch.
>
Great; thanks!
Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
On Feb 14 20:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Hi all,
>
> It looks like the cygrunsrv utility hardcodes 30 seconds as a maximal time
> for a service to start, then bails
> out with a failure.
>
> It would be quite useful (in certain situations) to have a command-line
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!
> It looks like the cygrunsrv utility hardcodes 30 seconds as a maximal time
> for a service to start, then bails out with a failure.
No, 30 seconds is a hard system timeout in which a service must reply with an
appropriate control message to let s
On Feb 15 14:44, Andrey Repin wrote:
> Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!
>
> > It looks like the cygrunsrv utility hardcodes 30 seconds as a maximal time
> > for a service to start, then bails out with a failure.
>
> No, 30 seconds is a hard system timeout in which a service must r
Greetings, Corinna Vinschen!
> On Feb 15 14:44, Andrey Repin wrote:
>> Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!
>>
>> > It looks like the cygrunsrv utility hardcodes 30 seconds as a maximal time
>> > for a service to start, then bails out with a failure.
>>
>> No, 30 seconds is a hard sy
201 - 300 of 373 matches
Mail list logo
