Re: Issues with TCP Window Scaling Factor and Cygwin Daemons

[Lee]

On 12/15/11, Dave Korn wrote:
> On 15/12/2011 05:23, Lee wrote:
>> On 12/14/11, David Groves wrote:
>>> I am having some issues with cygwin applications (specifically sshd)
>>> and TCP Window Scaling Factors. I am using OpenSSH client on either a
>>> Debian Linux or FreeBSD machine to connect to sshd on a Windows 2k8 R2
>^^
>>> server.
>
>> No pointers, but it does look like a Cygwin problem.
>>
>> Start up wireshark on a Windows XP machine and ssh (from a cygwin
>   ^^
>> window) to another machine - tcp syn packet has a window size of 65535
>> and a widow scale of zero.  Use putty from the dos prompt to ssh to
>> the same machine and that has a window size of 65535 and a window
>> scale of 2
>
>   1.  MS completely replaced the networking stack in Vista/2k8 with their
> so-called "Next Generation TCP/IP stack", so you can't extrapolate from XP
> to 2k8.

Arguh..  I don't know where I got WinXP from.  Sorry for the noise.
Lee



>   2.  On XP, window scaling is enabled by a registry setting, and when it is
> in effect, Windows decides what scale setting to use by considering the
> SO_RCVBUF size used when the connection is initiated.  In that light, the
> fact
> that Cygwin applications show a scale of zero is probably not unrelated to
> this snippet of code from net.cc#fdsock():
>
>>   /* Raise default buffer sizes (instead of WinSock default 8K).
>>
>>  64K appear to have the best size/performance ratio for a default
>>  value.  Tested with ssh/scp on Vista over Gigabit LAN.
>>
>>  NOTE.  If the SO_RCVBUF size exceeds 65535(*), and if the socket is
>>  connected to a remote machine, then calling WSADuplicateSocket on
>>  fork/exec fails with WinSock error 10022, WSAEINVAL.  Fortunately
>>  we don't use WSADuplicateSocket anymore, rather we just utilize
>>  handle inheritance.  An explanation for this weird behaviour would
>>  be nice, though.
>>
>>  (*) Maximum normal TCP window size.  Coincidence?  */
>>   ((fhandler_socket *) fd)->rmem () = 65535;
>>   ((fhandler_socket *) fd)->wmem () = 65535;
>>   if (::setsockopt (soc, SOL_SOCKET, SO_RCVBUF,
>>  (char *) &((fhandler_socket *) fd)->rmem (), sizeof (int)))
>> {
>   [ ... snip error handling ... ]
>> }
>
>   I would guess that a >65536 default would cause Windows to send a non-zero
> scale in the SYN packet, but as the comment says, that created some other
> sort
> of problem somehow.
>
>   3.  On 2k8 (also Vista and 7), window scaling is no longer controlled by
> the
> registry but enabled automatically, as part of a new feature called "Receive
> Window Auto-Tuning".  I could not infer from any documentation that I could
> find in ten minutes googling whether or not it still pays attention to the
> initial SO_RCVBUF setting.  It might be worth trying a custom build of the
> Cygwin DLL with a 64k or 128k setting in place of 65535.  Then again, it
> seems
> there may yet be problems in this functionality, e.g. the known bug
> described
> at http://support.microsoft.com/kb/983528; perhaps if the custom Cygwin DLL
> doesn't help, that hot-fix might.
>
> cheers,
>   DaveK
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

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

Re: Issues with TCP Window Scaling Factor and Cygwin Daemons

[Corinna Vinschen]

On Dec 15 05:39, Dave Korn wrote:
> On 15/12/2011 05:23, Lee wrote:
> > On 12/14/11, David Groves wrote:
> >> I am having some issues with cygwin applications (specifically sshd)
> >> and TCP Window Scaling Factors. I am using OpenSSH client on either a
> >> Debian Linux or FreeBSD machine to connect to sshd on a Windows 2k8 R2
>^^
> >> server.
> 
> > No pointers, but it does look like a Cygwin problem.
> > 
> > Start up wireshark on a Windows XP machine and ssh (from a cygwin
>   ^^
> > window) to another machine - tcp syn packet has a window size of 65535
> > and a widow scale of zero.  Use putty from the dos prompt to ssh to
> > the same machine and that has a window size of 65535 and a window
> > scale of 2
> 
>   1.  MS completely replaced the networking stack in Vista/2k8 with their
> so-called "Next Generation TCP/IP stack", so you can't extrapolate from XP to 
> 2k8.
> 
>   2.  On XP, window scaling is enabled by a registry setting, and when it is
> in effect, Windows decides what scale setting to use by considering the
> SO_RCVBUF size used when the connection is initiated.  In that light, the fact
> that Cygwin applications show a scale of zero is probably not unrelated to
> this snippet of code from net.cc#fdsock():
> 
> >   /* Raise default buffer sizes (instead of WinSock default 8K).
> > 
> >  64K appear to have the best size/performance ratio for a default
> >  value.  Tested with ssh/scp on Vista over Gigabit LAN.
> > 
> >  NOTE.  If the SO_RCVBUF size exceeds 65535(*), and if the socket is
> >  connected to a remote machine, then calling WSADuplicateSocket on
> >  fork/exec fails with WinSock error 10022, WSAEINVAL.  Fortunately
> >  we don't use WSADuplicateSocket anymore, rather we just utilize
> >  handle inheritance.  An explanation for this weird behaviour would
> >  be nice, though.
> > 
> >  (*) Maximum normal TCP window size.  Coincidence?  */
> >   ((fhandler_socket *) fd)->rmem () = 65535;
> >   ((fhandler_socket *) fd)->wmem () = 65535;
> >   if (::setsockopt (soc, SOL_SOCKET, SO_RCVBUF,
> > (char *) &((fhandler_socket *) fd)->rmem (), sizeof (int)))
> > {
>   [ ... snip error handling ... ]
> > }
> 
>   I would guess that a >65536 default would cause Windows to send a non-zero
> scale in the SYN packet, but as the comment says, that created some other sort
> of problem somehow.
> 
>   3.  On 2k8 (also Vista and 7), window scaling is no longer controlled by the
> registry but enabled automatically, as part of a new feature called "Receive
> Window Auto-Tuning".  I could not infer from any documentation that I could
> find in ten minutes googling whether or not it still pays attention to the
> initial SO_RCVBUF setting.  It might be worth trying a custom build of the
> Cygwin DLL with a 64k or 128k setting in place of 65535.  Then again, it seems
> there may yet be problems in this functionality, e.g. the known bug described
> at http://support.microsoft.com/kb/983528; perhaps if the custom Cygwin DLL
> doesn't help, that hot-fix might.

Alternatively we could only set the send/recv buffer sizes if we're
running under pre-Vista.  However, I have no idea what implications
this has in terms of network performance.  "Somebody" would have to
test it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

1.7 support SIGIO/SIGPOLL?

[Seabra]

Hello!

 Does cygwin 1.7 support SIGIO/SIGPOLL?

Thanks,
 Seabra

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

Re: GNU Emacs 23.3.1 problem with 20111213 snapshot

[Ken Brown]

On 12/14/2011 4:36 PM, Jim Reisert AD1C wrote:

[I posted this on the Cygwin-X list by mistake, I meant to post it here.]

I'm having a problem with the 20111213 snapshot.  I'm running GNU
Emacs 23.3.1 (emacs-x11) in a Cygwin-X window.  Windows XP SP3.

If I try to reverse-search inside a file (control-R) and the search
string is no longer found, after a couple more tries (more control-R),
the Emacs window will close and disappear.  There is no core dump.
Fortunately, the times when this happened, I had already saved the
buffer.

This is fairly repeatable.


I just tried to reproduce your problem using the 20111214 snapshot, and 
I couldn't.  My system is different, however (Windows 7).  In addition, 
I'm running a pretest of emacs 24.1 rather than 23.3.  Could you see if 
you still have the problem with the 20111214 snapshot (and with emacs 
started with the `-Q' option)?  If so, I'll try to duplicate your situation.


Just to make sure we're talking about the same thing, here's what I did: 
 I ran emacs under X, and it started in the *GNU Emacs* buffer.  I did 
a reverse search for "emacs" and kept pressing control-r, so that the 
search wrapped around and kept wrapping.  I probable pressed control-r 
20 or 30 times.


By the way, does the problem occur only under X, or can you reproduce it 
with emacs running in the Cygwin Terminal (mintty)?


Ken


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

Re: Broken dependencies? Bad Mirrors causing hidden problems? Was Re: New Installation fails: cygreadline7.dll not found.

[Larry Hall (Cygwin)]

On 12/14/2011 11:38 PM, Richard Troy wrote:




For that matter, can I download an ISO image from somewhere and thus
guarantee I get the whole thing? Buy a DVD?


Probably the easiest way to do this is rsync from cygwin.com.  Using any
currently listed mirror site should get you the same thing in general too.
Chris Faylor was offering DVDs at one point.  Don't know if he still is.
Others may be too.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: GNU Emacs 23.3.1 problem with 20111213 snapshot

[Jim Reisert AD1C]

On Thu, Dec 15, 2011 at 8:02 AM, Ken Brown wrote:

> I just tried to reproduce your problem using the 20111214 snapshot, and I
> couldn't.  My system is different, however (Windows 7).  In addition, I'm
> running a pretest of emacs 24.1 rather than 23.3.  Could you see if you
> still have the problem with the 20111214 snapshot (and with emacs started
> with the `-Q' option)?  If so, I'll try to duplicate your situation.

Thanks for testing, Ken.  I updated to the 1214 snapshot and the
problem *seems* to be gone.  It may be worth backing down to the 1213
snapshot to see if you can reproduce that problem, it may return if
it's not understood.

> Just to make sure we're talking about the same thing, here's what I did:  I
> ran emacs under X, and it started in the *GNU Emacs* buffer.  I did a
> reverse search for "emacs" and kept pressing control-r, so that the search
> wrapped around and kept wrapping.  I probable pressed control-r 20 or 30
> times.

That's pretty much what I did.

> By the way, does the problem occur only under X, or can you reproduce it
> with emacs running in the Cygwin Terminal (mintty)?

I did not try within mintty, though I guess I could,   I'd have to go
back to the 1213 snapshot.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

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

Re: GNU Emacs 23.3.1 problem with 20111213 snapshot

[Ken Brown]

On 12/15/2011 12:56 PM, Jim Reisert AD1C wrote:

On Thu, Dec 15, 2011 at 8:02 AM, Ken Brown wrote:


I just tried to reproduce your problem using the 20111214 snapshot, and I
couldn't.  My system is different, however (Windows 7).  In addition, I'm
running a pretest of emacs 24.1 rather than 23.3.  Could you see if you
still have the problem with the 20111214 snapshot (and with emacs started
with the `-Q' option)?  If so, I'll try to duplicate your situation.


Thanks for testing, Ken.  I updated to the 1214 snapshot and the
problem *seems* to be gone.  It may be worth backing down to the 1213
snapshot to see if you can reproduce that problem, it may return if
it's not understood.


Just to make sure we're talking about the same thing, here's what I did:  I
ran emacs under X, and it started in the *GNU Emacs* buffer.  I did a
reverse search for "emacs" and kept pressing control-r, so that the search
wrapped around and kept wrapping.  I probable pressed control-r 20 or 30
times.


That's pretty much what I did.


By the way, does the problem occur only under X, or can you reproduce it
with emacs running in the Cygwin Terminal (mintty)?


I did not try within mintty, though I guess I could,   I'd have to go
back to the 1213 snapshot.


I don't think it's worth the trouble, unless the problem comes back.

Ken


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

Re: GNU Emacs 23.3.1 problem with 20111213 snapshot

[Christopher Faylor]

On Thu, Dec 15, 2011 at 01:10:14PM -0500, Ken Brown wrote:
>On 12/15/2011 12:56 PM, Jim Reisert AD1C wrote:
>> On Thu, Dec 15, 2011 at 8:02 AM, Ken Brown wrote:
>>
>>> I just tried to reproduce your problem using the 20111214 snapshot, and I
>>> couldn't.  My system is different, however (Windows 7).  In addition, I'm
>>> running a pretest of emacs 24.1 rather than 23.3.  Could you see if you
>>> still have the problem with the 20111214 snapshot (and with emacs started
>>> with the `-Q' option)?  If so, I'll try to duplicate your situation.
>>
>> Thanks for testing, Ken.  I updated to the 1214 snapshot and the
>> problem *seems* to be gone.  It may be worth backing down to the 1213
>> snapshot to see if you can reproduce that problem, it may return if
>> it's not understood.
>>
>>> Just to make sure we're talking about the same thing, here's what I did:  I
>>> ran emacs under X, and it started in the *GNU Emacs* buffer.  I did a
>>> reverse search for "emacs" and kept pressing control-r, so that the search
>>> wrapped around and kept wrapping.  I probable pressed control-r 20 or 30
>>> times.
>>
>> That's pretty much what I did.
>>
>>> By the way, does the problem occur only under X, or can you reproduce it
>>> with emacs running in the Cygwin Terminal (mintty)?
>>
>> I did not try within mintty, though I guess I could,   I'd have to go
>> back to the 1213 snapshot.
>
>I don't think it's worth the trouble, unless the problem comes back.

I agree.  Since one of the intents of the 1214 snapshot was to deal with
the "bad address" problems that people were reporting, I'd say that this
was just another manifestation of that.

cgf

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

Re: Symlinks and sharing a home directory between Windows and Linux

[Andrew DeFaria]

On 12/14/2011 2:32 PM, Andrew DeFaria wrote:

On 12/14/2011 12:14 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:

Might CYGWIN=winsymlinks help?
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html
I don't see how. I think that I need the .lnk portion of the file. 
It's not clear to me from that link's description that setting 
winsymlinks gives me .lnk.


Hmmm... Just tested. Ah yes! The winsymlinks seems to do the trick! 
Thanks!

More:
http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking
http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks


Thanks for the references...
I'm not sure this is working as well as I had hoped (or remembered). I 
think the question boils down to, given a Unix symlink of say 
.bash_login and a Cygwin symlink of say .bash_login.lnk, which does 
Cygwin read when logging it? I would have hoped that Cygwin would always 
see the .lnk file whereas Unix would see the regular symlink. That's how 
I thought this worked before. But it doesn't seem to be working that 
way. In fact I see:


$ ls -l .bash*
-rw-r--r-- 1 adefaria clearusers 7179 Dec 15 15:35 .bash_history
-rw-r--r-- 1 adefaria clearusers   29 Dec 15 14:36 .bash_login
-rw-r--r-- 1 adefaria clearusers   29 Dec 15 14:36 .bash_login
-rw-r--r-- 1 adefaria clearusers   29 Dec 15 14:36 .bashrc
-rw-r--r-- 1 adefaria clearusers   29 Dec 15 14:36 .bashrc

When I login bash see the Unix formated .bash_login symlink and chokes. 
I can remove this Unix symlink from the Unix side and log in with bash 
again and it works. If I remake the symlink on the Unix side it fails! :-(


I don't remember this being a problem before. I fear this is a Samba 
config thing...


Note: CYGWIN has winsymlinks in it...
--
Andrew DeFaria 
Law of Probability Dispersal: Whatever it is that hits the fan will not 
be evenly distributed.



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

ocaml: 3.12.1-1 missing HAS_SOCKETS

[Yaakov (Cygwin/X)]

Damien,

There is a problem with the Unix library in the new ocaml-3.12.1-1:

$ ocaml
Objective Caml version 3.12.1

# #load "unix.cma" ;;
Exception: Invalid_argument "inet_addr_of_string not implemented".

Looking at the sources[1], it seems you compiled ocaml without
HAS_SOCKETS.  This needs to be fixed and 3.12.1-2 released ASAP.

In particular, this commit[2] needs to be reversed, although I don't
know if that is the cause.  While you're at it, you could fix the
false negative in the bfd detection[3] by adding -lintl to the
libraries in the second hasgot test.


Yaakov

[1] 
http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/release/3.12.1/otherlibs/unix/addrofstr.c?view=markup
[2] 
http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/release/3.12.1/configure?r1=11064&r2=11106
[3] 
http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/release/3.12.1/configure?r1=10619&r2=10626

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

Igncr ineffective?

[manu0507]

Hello,

I'm running Cygwin 1.7.9-1 on Win7-64, with "GNU bash, version
4.1.10(4)-release (i686-pc-cygwin)".

When executing a script (a gdb build script) with CR/LF line ends, bash
reports errors on "unusual" lines of the script, even with igncr set. Here
is an example with the script "configure":

Manu@Holland /cygdrive/d/Installs/gdb_7_3_1/gdb-7.3.1
$ ./configure
./configure: line 14: $'\r': command not found
./configure: line 29: syntax error near unexpected token `newline'
'/configure: line 29: ` ;;

... where all lines end with CR/LF, but
line 14 is the first empty line in the script
line 29 is the first one ending with ";;CR/LF".

This clearly smacks of line-end problems and, indeed, when all CR/LFs are
replaced by LFs only, the script runs ok... until it tries to call another
script with the same problem.

I could manually convert all scripts to LFs only, but I'd really prefer to
avoid that (could wreak havoc!), so my question is: isn't setting igncr
supposed to make bash ignore the CRs in CR/LFs? If not, is there something
else I can do to make it do so? And if so (i.e. this a bug), is there a
correction to be had?


Many thanks,

Emanuel

-- 
View this message in context: 
http://old.nabble.com/Igncr-ineffective--tp32983438p32983438.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Igncr ineffective?

[Eric Blake]

On 12/15/2011 05:43 PM, manu0507 wrote:
> 
> Hello,
> 
> I'm running Cygwin 1.7.9-1 on Win7-64, with "GNU bash, version
> 4.1.10(4)-release (i686-pc-cygwin)".
> 
> When executing a script (a gdb build script) with CR/LF line ends, bash
> reports errors on "unusual" lines of the script, even with igncr set. Here
> is an example with the script "configure":

How are you setting igncr?  Did you read the release announcement that
you now have to use 'set -o' and not 'shopt -s' to set it?  The full
details are here:

http://cygwin.com/ml/cygwin-announce/2011-02/msg00027.html

> I could manually convert all scripts to LFs only, 

And that would be my preferred solution, as that is the most Linux-like,

> but I'd really prefer to
> avoid that (could wreak havoc!),

which is why igncr exists, for people unwilling to use sane line endings
in the first place.

> so my question is: isn't setting igncr
> supposed to make bash ignore the CRs in CR/LFs? If not, is there something
> else I can do to make it do so? And if so (i.e. this a bug), is there a
> correction to be had?

No one else has reported that igncr is broken as implemented, so most
likely a bug in your usage and you didn't actually enable it like you
thought you had.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: "Bad address" error while building cygwin with make -j2

[Chris Sutcliffe]

On 15 December 2011 02:16, Heiko Elger wrote:
> I tested it - still same issue!
>
> *** snip snp snip **
> $ uname -a
> CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 20111214 15:56:36 i686 Cygwin
>
> $ make -j2



> make: *** read jobs pipe: Bad address.  Stop.
> make: *** Waiting for unfinished jobs
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 2!

I'm not sure if the 20111214 snapshot was supposed to address this
issue, but I'm continuing to experience the issue as well:

csutclif@bmotec3017201lt:[~] $ uname -a
CYGWIN_NT-5.1 BMOTEC3017201LT 1.7.10s(0.255/5/3) 20111214 15:56:36 i686 Cygwin

csutclif@bmotec3017201lt:[/usr/src/vim] $ make -j4
Starting make in the src directory.
If there are problems, cd to the src directory and run make there
cd src && make first
make[1]: Entering directory `/usr/src/vim/src'
gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/buffer.o buffer.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/blowfish.o blowfish.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/charset.o charset.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/diff.o diff.c
make[1]: *** read jobs pipe: Bad address.  Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/usr/src/vim/src'
Makefile:26: recipe for target `first' failed
make: *** [first] Error 2
make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Services aren't running

[Mike Brown]

The upgrade from 1.5 to 1.7 broke the starting of the services.  I just
noticed that there are no services running when I do a "ps."  That means
cron isn't working either.

What did the 1.7 install do to break the services that I had running and why
didn't it set them up do start at boot time?

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
[I've been to Earth.  I know where it is. ]  \ / Ribbon Campaign
[And I'm gonna take us there.Starbuck  3/25/07]   X  Against
Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML Email

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

Re: Services aren't running

[Rance Hall]

On Thu, Dec 15, 2011 at 9:03 PM, Mike Brown  wrote:
> The upgrade from 1.5 to 1.7 broke the starting of the services.  I just
> noticed that there are no services running when I do a "ps."  That means
> cron isn't working either.
>
> What did the 1.7 install do to break the services that I had running and why
> didn't it set them up do start at boot time?
>
> MB
> --

Just a hunch but did you remember to stop the old services before
doing the upgrade?  Windows can't mess with files that are locked and
in use.

I know that services work properly under 1.7.
Rance

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

Re: Services aren't running

[Mike Brown]

On Thu, Dec 15, 2011 at 09:07:24PM -0600, Rance Hall wrote:
> Just a hunch but did you remember to stop the old services before
> doing the upgrade?  Windows can't mess with files that are locked and
> in use.

The install stopped at that point and I had to kill it, before continuing.

It seems that "ps" is a little different in what it reports now.  I gather
that the server is no longer belonging to me, so it didn't show up.  I
just did a "ps -eaf" and there it is.

Now to find out why cron didn't do the job I scheduled.  Cron is also running,
so I have to figure out what went wrong.

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
[I've been to Earth.  I know where it is. ]  \ / Ribbon Campaign
[And I'm gonna take us there.Starbuck  3/25/07]   X  Against
Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML Email

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

Cron doesn't work after 1.7 upgrade

[Mike Brown]

The crontab entry that I had should have fired, but it didn't.  At 20:58 on
day 4 (Thu), the entry should have fired.

Doing a ps -eaf shows that the UID of cron is 0, not SYSTEM.  Is that an issue
with 1.7?  If so, how do I fix it?  If not, what can I do to find out why
cron failed to run my crontab entry?

OS is XP SP3

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
[I've been to Earth.  I know where it is. ]  \ / Ribbon Campaign
[And I'm gonna take us there.Starbuck  3/25/07]   X  Against
Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML Email

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

Re: Symlinks and sharing a home directory between Windows and Linux

[Larry Hall (Cygwin)]

On 12/15/2011 6:47 PM, Andrew DeFaria wrote:

On 12/14/2011 2:32 PM, Andrew DeFaria wrote:

On 12/14/2011 12:14 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:

Might CYGWIN=winsymlinks help?
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

I don't see how. I think that I need the .lnk portion of the file. It's
not clear to me from that link's description that setting winsymlinks
gives me .lnk.

Hmmm... Just tested. Ah yes! The winsymlinks seems to do the trick! Thanks!

More:
http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking
http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks


Thanks for the references...

I'm not sure this is working as well as I had hoped (or remembered). I think
the question boils down to, given a Unix symlink of say .bash_login and a
Cygwin symlink of say .bash_login.lnk, which does Cygwin read when logging
it? I would have hoped that Cygwin would always see the .lnk file whereas
Unix would see the regular symlink. That's how I thought this worked before.
But it doesn't seem to be working that way. In fact I see:

$ ls -l .bash*
-rw-r--r-- 1 adefaria clearusers 7179 Dec 15 15:35 .bash_history
-rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login
-rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login
-rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc
-rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc

When I login bash see the Unix formated .bash_login symlink and chokes. I
can remove this Unix symlink from the Unix side and log in with bash again
and it works. If I remake the symlink on the Unix side it fails! :-(

I don't remember this being a problem before. I fear this is a Samba config
thing...

Note: CYGWIN has winsymlinks in it...


I'm having difficulty seeing how what you have described could work unless
the consumers of these files are looking for symlinks only, which your
example above contradicts.  And both of the ".bashrc" files are registering
as plain files, so I think you're right that the file system on which they
reside is coming into play, assuming the output above is from Cygwin's
'ls'.  But even if you had ".bashrc" and ".bashrc.lnk" with the former
being a UNIX-form of symlink and the latter being the Cygwin one, I'd still
expect Cygwin to recognize ".bashrc" first and only go looking for the .lnk
version if it couldn't find that.  The output of strace may convince you
of that as well. ;-)  It might actually work as you describe it though if
you can get Cygwin to think that it can't open the former.  I could see that
being the case if the UNIX symlink was created by a user ID Cygwin didn't
recognize, for example.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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