Den 2024-04-20 14:12, skrev enrique--- via Cygwin:
$ cygrunsrv -I -p /usr/sbin/cron.exe -a -n
cygrunsrv: Trailing commandline arguments not allowed
Try `cygrunsrv --help' for more information.
[snip]
What am I doing wrong?
I found it: Missing service name after "-I".
-Thanks
--
Problem
On 2024-04-20 06:31, Eliot Moss via Cygwin wrote:
On 4/20/2024 8:12 AM, enrique--- via Cygwin wrote:
Hello,
I am trying to install a service manually in an attempt to understand why
cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten
On 4/20/2024 8:12 AM, enrique--- via Cygwin wrote:
Hello,
I am trying to install a service manually in an attempt to understand why
cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten Cron daemon ble stoppet.
$ cygrunsrv -R cron
$
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/
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.:
>
>
On Feb 5 09:15, Doug Henderson via Cygwin wrote:
> Hi,
>
> I tried to run "cygrunsrc -L" in both a regular and elevated shell. In both
> cases I received the same error messages. I do not believe I have any
> cygwin services configured.
>
> $ cygrunsrv -L
> cygrunsrv: warning:
Greetings, ASSI!
> Andrey Repin via Cygwin writes:
>> The question is a proverbial one: Who's guilty and what to do?
> You have more than one Cygwin installation (cygwin1.dll) and the path is
> different in different environments.
How should I know? Where it is documented?
(Also, it is the same
Andrey Repin via Cygwin writes:
> The question is a proverbial one: Who's guilty and what to do?
You have more than one Cygwin installation (cygwin1.dll) and the path is
different in different environments.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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:
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
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
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
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:
>
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
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
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 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 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.
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
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 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:
>
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
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 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 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
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
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
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 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 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
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
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
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 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 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 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
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/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
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
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
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
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 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
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
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
>
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
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
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]
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
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
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
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 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
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
On 2020-01-29 11:55, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> Don't see where you read that?
>
> The service control manager waits until the service stops or the specified
> preshutdown time-out value expires (this value can be set with the
> ChangeServiceConfig2 function).
> Don't see where you read that?
The service control manager waits until the service stops or the specified
preshutdown time-out value expires (this value can be set with the
ChangeServiceConfig2 function). This control code should be used only in
special circumstances, because a service that
On 2020-01-28 15:28, Brian Inglis wrote:
> On 2020-01-28 14:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>> As the reg entries show, you can also do this by adding or setting registry
>>> entries using Cygwin regtool, Windows reg, or regedit commands.
>>
>> It is better and much safer to use
On 2020-01-28 14:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> As the reg entries show, you can also do this by adding or setting registry
>> entries using Cygwin regtool, Windows reg, or regedit commands.
>
> It is better and much safer to use native Windows service controller
> commands,
On 2020-01-28 14:26, Andrey Repin wrote:
>> $ cygrunsrv -VQ cygsshd
>> Service : cygsshd
>> Display name: CYGWIN sshd
>> Current State : Running
>> Controls Accepted : Stop, Preshutdown
>> Command : /usr/sbin/sshd -D
>> stdin path : /dev/null
>>
> As the reg entries show, you can also do this by adding or setting registry
> entries using Cygwin regtool, Windows reg, or regedit commands.
It is better and much safer to use native Windows service controller commands,
than tweaking the registry:
sc config cygsshd start= delayed-auto
Also,
Greetings, Brian Inglis!
> $ cygrunsrv -VQ cygsshd
> Service : cygsshd
> Display name: CYGWIN sshd
> Current State : Running
> Controls Accepted : Stop, Preshutdown
> Command : /usr/sbin/sshd -D
> stdin path : /dev/null
> stdout path :
On Wed, Jan 22, 2020 at 03:08:12PM -0700, Brian Inglis wrote:
> I've used dnscache for network service dependencies (and cygserver and
> syslog-ng
> for other Cygwin services) with delayed start and preshutdown (cygrunsrv -O,
> --preshutdown).
> Where previous usage was cygrunsrv -t, --type
On 2020-01-22 15:08, Brian Inglis wrote:
> On 2020-01-22 11:18, ASSI wrote:
>> Andrew J. Schorr writes:
[add cygrunsrv output for completeness]
Try to set the service to "delayed start" instead and see if that helps.
>>>
>>> Thanks for the suggestion; that seems to fix the issue. Is this a
On 2020-01-22 11:18, ASSI wrote:
> Andrew J. Schorr writes:
>>> Try to set the service to "delayed start" instead and see if that helps.
>>
>> Thanks for the suggestion; that seems to fix the issue. Is this a known
>> problem due to some updates to Windows 10 and/or Cygwin? I have not had
>> this
Andrew J. Schorr writes:
>> Try to set the service to "delayed start" instead and see if that helps.
>
> Thanks for the suggestion; that seems to fix the issue. Is this a known
> problem due to some updates to Windows 10 and/or Cygwin? I have not had
> this problem in the past.
Win10 is better at
On Tue, Jan 21, 2020 at 09:37:15PM +0100, Achim Gratz wrote:
> Andrew J. Schorr writes:
> > How do I fix and/or troubleshoot this? I need to find a way to get
> > cygsshd to start automatically when the system reboots.
>
> Try to set the service to "delayed start" instead and see if that helps.
Andrew J. Schorr writes:
> This matches the configuration I have on a previously installed system
> running 3.0.7 that works correctly.
>
> The log file /var/log/cygsshd.log is empty. I have attached the output
> of "cygcheck -s -v -r > /tmp/cygcheck.out".
>
> How do I fix and/or troubleshoot
On Nov 12 19:41, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin-patches wrote:
> Hi,
>
> Looks like I finally prepared a patch for cygrunsrv that I mentioned as an
> added feature way back in Feb (I did not need to come around to that since
> then):
>
>
> git://sourceware.org/git/cygwin-apps/cygrunsrv.git
Thanks, that worked. I was using a static source archive (cygrunsrv-1.62) to
make all the changes, so didn't need git until now.
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin-patches writes:
> $ git clone 'https://cygwin.com/git/?p=cygwin-apps/cygrunsrv.git' ./cygrunsrv
> Cloning into './cygrunsrv'...
> fatal: repository 'https://cygwin.com/git/?p=cygwin-apps/cygrunsrv.git/' not
> found
Try
Greetings, Irfan Adilovic!
> (All actions here assume an elevated mintty terminal)
> I have the need to automate the installation of autossh as a windows
> service (=> several dozen autossh services) and when installing as a
> local user, the password prompt is an issue.
This is not an issue,
On Tue, 21 May 2019 at 04:20, Chris Wagner wrote:
>
> Hi Irfan,
>
> I'm assuming that there is some reason you don't want to use the
> password option:
> -w, --passwdOptional password for user. Only needed
> if a user is given. If a user has an empty
>
Hi Irfan,
I'm assuming that there is some reason you don't want to use the
password option:
-w, --passwdOptional password for user. Only needed
if a user is given. If a user has an empty
password, enter `-w '. If a user is given
but
> No, 30 seconds is a hard system timeout in which a service must reply with
> an appropriate control message to let services.exe know it is ready to
> continue startup sequence.
I don't think there is a hard-coded system timeout, as long as the starting
service keeps
posting its START_PENDING
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
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
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
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
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.
- 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
- 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 wrot
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
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
> 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
> 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
1 - 100 of 364 matches
Mail list logo
