>On 7/26/2015 5:24 PM, Jim Garrison wrote:
>> Google turned up one other question citing the same symptoms, but on a
>> Chinese website, no answers so far.
>>
>> cygcheck.out attached
>>
>> Suggestions on how to troubleshoot? I can provide an strace output
>> (67k lines, 460kB gzipped) if desi
> I was trying to install the new httpd (apache 2.4) package today, and can't
> seem to find the equivalent of the old /usr/sbin/httpd2-config file (which
> created the Windows service). Does that still exist? If so, can you please
> point me to where it lives now? Or is service creation now
I was trying to install the new httpd (apache 2.4) package today, and can't
seem to find the equivalent of the old /usr/sbin/httpd2-config file (which
created the Windows service). Does that still exist? If so, can you please
point me to where it lives now? Or is service creation now a manual
>You don't have a setup per chance that doesn't yet have network connectivity
>when cygserver starts up? Firewall >opened only when a user logs in? VPN
>needs time to establish connection? Is cygserver dependent on the tcpip
>>service?
No (at least not today and recently). I'm hardwired (Et
> What account is cygserver as service running under? Your own, or something
> like LocalSystem, or
> NetworkService?
In my case it is running under SYSTEM.
> - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two
> commands, and paste the output into your reply:
>getent passwd %USERNAME%
>id
I am able to produce the failure again (by reverting to cygserver starting
immediately as a service upon bootup). I would be happy to prov
>LDAP can't have to do with that, in theory. The whole mechanism should give a
>sane result even if LDAP >connections fail, because the core part is the call
>to LookupAccountSid and that's the only call which has to >succeed.
Certainly my speculation of the cause is exactly thatspeculatio
I observed the same error. In my case, it was apparently caused by a too-rapid
startup at boot of cygserver, which apparently could not connect to LDAP at
that early stage. If I prevented any of my Cygwin services from starting at
boot, and then started them manually once I logged in, the prob
> Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
> mask as returned by stat(2) or printed by ls(1), due to the improved
> POSIX ACL handling. As a temporary workaround, chmod now checks if
I'm a neophyte regarding this ACL handling stuff. Here is my usage model,
which
On 12/11/2014 3:17 PM, Gery . wrote:
>> So far things have been nicely working in my cygwin with postgres
>> and apache, thanks guys for the excellent job you're doing in
>> cygwin. The only thing is that when I stop apache2 and postgres, or
>> put in sleep mode my laptop, then I cannot start agai
> In the long run I'm also planning to allow replacing /etc/fstab and
> /etc/nsswitch.conf with a Cygwin-specific AD configuration extension.
While I can see how this might be attractive for some, I see it as something
that must be an optional replacement of the /etc/fstab and /etc/nsswitch.conf
> Thanks. Unfortunately it's not useful, because the actual problem
> occurred inside Cygserver. What I need would be the problem captured
> by running cygserver from the command line like this:
> $ strace -o cygserver.trace /usr/sbin/cygserver -d 2> cygserver.stderr
Strace output attached. A
> Does this record have one or more entries in the sidHistory attribute?
Yes, as you suspected, the sidHistory attribute for
S-1-5-21-1060284298-861567501-682003330-76794 contains
S-1-5-21-4015118-2039090470-1726288727-4013
> That's a bit of a problem for debugging. Did you notice my mail
> https://cygwin.com/ml/cygwin/2014-11/msg00480.html, btw?
Just taking a step back...what are we trying to fix? Once startup goes
smoothly, your current AD code works fine for me. The only problem I'm having
is that sometimes s
On Nov 25 16:24, Habermann, David (D) wrote:
> >> Still, some debugging on affected systems might be enlightening.
>
> > I'll be happy to do anything of interest. As a starter, I'm going
> > to see if I can figure out which of my SIDs are being used by the
>
> Two things to keep in mind:
> - It's not actually clear yet if it's a sidHistory entry or some SID
> created by another mechanism.
> Even if it's sidHistory, it may be *very* old. Did you work at the
> company already back in NT4 times? That might explain the sidHistory
> entry and the tot
>> Still, some debugging on affected systems might be enlightening.
> I'll be happy to do anything of interest. As a starter, I'm going
> to see if I can figure out which of my SIDs are being used by the
> couple of file shares I routinely access from cygwin.
I was unable to quickly figure out
> Thanks. Unfortunately it's not useful, becasue the actual problem
> occurred inside Cygserver. What I need would be the problem captured
> by running cygserver from the command line like this:
> $ strace -o cygserver.trace /usr/sbin/cygserver -d 2> cygserver.stderr
> and see the two files cy
> > Stopping the terminal and restarting cygserver is not sufficient?
> > Also, does this also happen if you don't start cygserver at all?
>
> I've not tried either of these ... and I'm not sure if it happens at
> every reboot now or not (I rarely reboot). I'll see if I can
> reproduce it.
>
> >
>> I've not tried either of these ... and I'm not sure if it happens at
>> every reboot now or not (I rarely reboot). I'll see if I can
>> reproduce it.
>>
>> > When the problem occurs, can you provide an strace from id?
>> >
>> > $ strace -o id.trace /usr/bin/id
>>
>> Will do if I can get it t
-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: Tuesday, November 18, 2014 10:58 AM
To: cygwin@cygwin.com
Subject: Re: occasional failure to look up
On Nov 18 15:49, Habermann, David (D) wrote:
> > Do you logi
> Do you login with your Microsoft account?
I am logged into my workstation using the id "DOW\U074036". Of course the
services I mentioned to not run under my ID, but instead under "SYSTEM" (except
sshd, which uses privsep)
> Is 1125370 your primary group id? Can you please paste the output o
I am using the AD-enabled cygwin test versions (v33-0.5), with nsswitch.conf
setting to "db" only.
Occasionally when starting a cygwin terminal after a reboot I find that it get
the following message:
/usr/bin/id: cannot find the name for group ID 1125370
Note that this is not a group ID, but
> current scenario. Besides, it is nice to have the Cygwin HOME
> directory isolated to the Cygwin installation for a portable install
> that can be used on a USB thumb drive.
I hadn't even thought about thumb drive/portable use since I hadn't used mine
for a while. I, too, will have to work ar
>> I also like having everything stored under one main directory (c:\cygwin)
>> for ease of backup
> Why would you back up all of c:\cygwin? Most of it is downloaded from the
> Internet, and this is easily
> reinstalled from your cached download. (I'm assuming you keep setup.exe and
> its dow
>>> Another:
>>>
>>> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>>> the above:
>>>
>>> home: [unix|win|home]...
>>>
>>>- "unix" means, set pw_dir to unixHomeDirectory
>>>- "win" means, set pw_dir to homeDirectory
>>>- "home" means, set pw_dir to /home
On Nov 5 22:38, Habermann, David (D) wrote:
>> It would appear, after a bit more digging, that this problem is
>> related to some timeout issues. Most of the time the ssh login goes
>> rapidly, but occasionally it takes quite a lot longer triggering the
>> expect defaul
>> I just released a 5th TEST version of the next upcoming Cygwin release,
>> 1.7.33-0.5.
> Ever since using this 1.7.33-0.x series (currently running 1.7.33-0.5)
> I've been having intermittent trouble with one of my scripts, and just
> finally got around to digging further today. This is an e
> I just released a 5th TEST version of the next upcoming Cygwin release,
> 1.7.33-0.5.
Ever since using this 1.7.33-0.x series (currently running 1.7.33-0.5) I've
been having intermittent trouble with one of my scripts, and just finally got
around to digging further today. This is an expect sc
>>> ... would you mind to test a new incarnation of ssh-user-config which I
>>> plan to use in a bugfix-release of OpenSSH 6.7p1 and to push upstream. :}
>> Test completed, it worked fine in my environment (although the file did
>> need a d2u prior to running). I generated all three primary keys
>>> On Oct 28 20:22, Habermann, Dave (DA) wrote:
>> On my Windows 7 machine, the service is tcpip, not tcp. Running
>>> sc config cygserver depend= tcp/afd
>TCPIP and AFD are two separate services.
Yes, but this is the syntax used to identify the two separate services in the
SC CONFIG comman
> ... would you mind to test a new incarnation of ssh-user-config which I
> plan to use in a bugfix-release of OpenSSH 6.7p1 and to push upstream. :}
Test completed, it worked fine in my environment (although the file did need a
d2u prior to running). I generated all three primary keys and they
32 matches
Mail list logo
