Re: slow startup after upgrade
On Feb 24 16:03, q2t2hzm...@snkmail.com wrote: > Corinna Vinschen corinna-cygwin-at-cygwin.com |cygwin_ml_nodigest| wrote at > 22:13 +0100 on Feb 24, 2015: > > Hi Roger, > > > > On Feb 24 19:55, Roger Orr wrote: > > > Hello Corinna, > > > It seems slightly faster than the previous patch and I've not noticed a > > > downside yet. > > > > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 i686 > > > Cygwin: > > > > > > ~37ms to run echo.exe from Windows command prompt > > > ~60ms to run .\id.exe -a from Windows command prompt > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 i686 > > > Cygwin: > > > > > > ~35ms to run echo.exe from Windows command prompt > > > ~53ms to run .\id.exe -a from Windows command prompt > > > > That's a nice result. > > > > However, I don't quite understand this result for the older DLL. > > Weren't you reporting >4 secs as startup time from 1.7.35?!? > > > > On another note: > > > > I just uploaded a new developer snapshot (2015-02-24). This snapshot > > should improve mkpasswd/mkgroup or, generally speaking, enumerating AD > > accounts, a lot. Can you give it a try? > > > > While you're at it, does the new snapshot still stop after 3.5K accounts > > even though you think there are 8K accounts? If so, I'd be interested > > to investigate this further. The reason is, while testing my today's > > performance improvements, I stumbled over a bug in my code which also > > resulted in enumerating less accounts as desired. So I'm not entirely > > sure your problem isn't related to a bug either. > > That mkpasswd symptom was reported by me Really? This is the first time I see your email address on this ML, and there's no name connected to it, so I don't even know if you're usually writing under another email address. At least a forename would be nice... > (well, maybe others, too). > I'm running it again, but it's still very slow, AFAICS. It shouldn't. It performs only one LDAP call now per 100 accounts, If that's still slow in your environment, I don't see any way to speed this up any further. > I'll report > how long it took when / if it finishes. > > New issue with recent snaps: > > Running the 20150224 (and *23) snapshot produces the following on Win > XP (yes, I know) if cygserver is running: Sidenote: I'm contemplating to stop supporting XP end of this year. > $ /usr/sbin/syslog-ng -F > 1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** fatal > error - Fetching account info from cygserver with wrong arg.type 2 Try the snapshot I just uploaded (2015-02-25). I forgot a tiny, but crucial statement in the code when I changed that code two days ago. That should be fixed now. > tcsh still taking a long time here (also XP - 3+ minutes with > cygserver running). bash & dash much quicker. Works very quickly for me. Problem is, I don't know anything about your environment. Are you working remote or in an office? How many groups are in your user token? What is the result of this funny little statement Dennis created: cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo !TIME!" Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYdl2bumxgn.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 24 18:10, Warren Young wrote: > > On Feb 24, 2015, at 5:23 PM, Andrey Repin wrote: > > > > Basically speaking, yes, chgrp to anything other than your user SID, > > followed > > by `chmod 600`, should help. > > I’ve checked in a change to that FAQ item giving this as the official > solution. Thanks. Just two hints: - Group "None" is a local group and changing to None is not such a bright idea for domain users. "Domain Users" may be better here, - Group "None" is a localized group, called, e.g. "Kein" in (really really terrible) german. Maybe that should be mentioned. Same for "Domain Users", of course. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXwFy0cxos9.pgp Description: PGP signature
Re: chgrp in Windows
On Feb 25 02:49, lemke...@t-online.de wrote: > On Wed, 25 Feb 2015 02:35:50 +0100 Andrey Repin wrote: > >>> The result of chown I can see in Windows Explorer as the Owner but > >>> where is the group information? > >> > >> Itâs over on the Security tab of the same window youâre looking at: > >> âGroup or user namesâ. > > > >I just remembered that that tab isnât always visible. If youâre running > >a âhomeâ version of Windows, thereâs a pretty good chance you donât even > >see this tab. > >>> > Thanks for that. I first thought that's it. I am on XP Pro so this > doesn't seem to apply. I do see the security tab > if that is what you mean. But the 'Group or user names' box only > selects > for which user/group I want to modify > the permissions, doesn't it? I don't want to modify or look at > permissions. > >>> > I am actually looking for the information I see in ls -l as the group, > i.e. column #4. > >>> > I am trying to fix a completely hosed file system and seem to have quite > a > bit of trouble with that... Something's still missing. > >>> > >>>If you mean Cygwin system, reinstall would be a faster way. > > > >> Unfortunately, it's the whole PC, which is also the reason why I have to > >> use this terrible webmailer, sorry. > > > >Then there's an article on Microsoft KB explaining the way to re-initialize > >the default permissions on system folders. > > > >However, this is an off-topic here. > > > > Absolutely. So let's stick to this question: > > How to do the equivalent of chgrp with Windows means? Not with Windows on-board tools, and it shouldn't even be necessary. The primary group entry has *no* relevance for native Windows tools, thus its setting is irrelevant. What really counts is the owner and the DACL. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4GKFOLL4OY.pgp Description: PGP signature
Re: slow startup after upgrade
On Feb 24 23:57, Roger Orr wrote: > Corinna Vinschen wrote: > > While you're at it, does the new snapshot still stop after 3.5K > > accounts even though you think there are 8K accounts? At this point I think I mix you up with John Hein, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3eZ7HxksYI.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
Hi John, On Feb 23 10:22, John Hein wrote: > Corinna Vinschen corinna-cygwin-at-cygwin.com |cygwin_ml_nodigest| wrote at > 12:17 +0100 on Feb 23, 2015: > > 1.7.33: > > > > Calls NetUserEnum/NetGroupEnum,NetLocalGroupEnum with maximum Buffer > > size. > > > > 1.7.34+: > > > > Calls an LDAP enumerator fetching 100 SIDs per call. > > For each SID: > > Call LookupAccountSid. > > For each User: > > Depending on nsswitch.conf, call LDAP to fetch the extended passwd > > info (pw_shell, pw_home, pw_gecos). > > > > I guess there's some room for improvement. > > > > OTOH, keep in mind that you're not suppsoed to call mkpasswd/mkgroup > > to enumerate your entire organization. If you're using it at all, then > > only to create the required entries in /etc/passwd and /etc/group for > > your local acocunt to work, and then leave everything else to the "db" > > setting. > > Fair enough. I'll stop stress testing mkpasswd and consider this > closed unless there's something we want to try. > > But 1.7.33 seems much faster (if you can call 50 minutes fast) at it > than 1.7.34-6 or 1.7.35-0.3 in this large-ish AD. Maybe a knob to > specify buffer size and/or some other knobs might help identifying the > slowest parts (and/or some stats). Just a thought. > > I'll add that the 1.7.34-6 'strace mkpasswd -d' that I had started > above finished in 20+ hours and spewed ~3500 of ~8000 entries. Can you retry this test with the latest developer snapshot (2015-02-25) from https://cygwin.com/snapshots/, please? As I already said in other mails to this list, I rewrote the code doing the LDAP lookup for the getpwent/getgrent calls, as well as for mkpasswd/mkgroup. I reduced the number of LDAP calls to 1 call per 100 users, with no intermediate LDAP call within. This should become as fast as it can get. It may still be slower than pre-1.7.34, but that is a bit unfair considering the more complext setup using various different AD attributes depending on the settings in /etc/nsswitch.conf. OTOH, the number of accounts per LDAP call (100) is a fixed number right now. It might be prudent to use a different, higher number in calls to mkpasswd/mkgroup, compared to a "real" getpwent/getgrent, let's say, 1000. That might give us another performance gain, but needs testing in a big environment like yours, of course. As for stopping after 3500 of 8000 accounts, I'd be interested to investigate this further, as I accidentally addressed to Roger Orr. As I outlined in that mail, I stumbled over a bug in my code which also resulted in enumerating less accounts as desired. So I'm not entirely sure your problem isn't related to a bug either. So, first thing first, does that problem still exist with the snapshot? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpwEOQmPaI1_.pgp Description: PGP signature
Re: slow startup after upgrade
Corinna Vinschen cygwin.com> writes: > > > While you're at it, does the new snapshot still stop after 3.5K > > > accounts even though you think there are 8K accounts? $ mkpasswd -d | wc I get ~30k AD accounts back in 75s instead of 315s and the network traffic is only half of the former value as well comparing the 20150224 vs. the latest 20150223 snapshot. Regards, Achim. -- 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: slow startup after upgrade
On Feb 25 12:29, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > > > While you're at it, does the new snapshot still stop after 3.5K > > > > accounts even though you think there are 8K accounts? > > $ mkpasswd -d | wc > > I get ~30k AD accounts back in 75s instead of 315s and the network traffic > is only half of the former value as well comparing the 20150224 vs. the > latest 20150223 snapshot. Cool! Thanks for your feedback. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpv6vxf9UsAG.pgp Description: PGP signature
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
Hi Cygwin friends and users, I released another TEST version of the next upcoming Cygwin release. The version number is 1.7.35-0.4. This release introduces a rewrite of the functions being the main culprit for the slowness of fetching account information from AD. There are still a few potential ways to hone the results, but code-wise there isn't a lot left to do anymore. Another important change in this release is a change to chmod. As many of you experienced 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 secondary groups and users in the ACL have more permissions than the primary group. If so, the permissions of the secondary users and groups will be reduced according to the mask given by the new primary group permissions. I.e, chmod 600 will remove all permissions from the primary group as well as all secondary user and group entries in the ACL. Please report back your experience, especially if you're still suffering from "slow startup" problems. If you're not familiar with the new account information handling introduced in Cygwin 1.7.34, I suggest to read the new documentation at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping Please also note this change of the default settings for db_home, db_shell, and db_gecos since 1.7.35-0.3: db_home: /home/%U db_shell: /bin/bash db_gecos: This means, if you don't set these values in /etc/nsswitch.conf, there's no reason for Cygwin to access the DC via LDAP. Other changes in this release: == - New APIs: cabsl, cimagl, creall, finitel, hypotl, sqrtl. - Fix /proc/cpuinfo multicore info on Intel CPUs. Addresses: https://cygwin.com/ml/cygwin-apps/2015-02/msg00077.html - Generate unique inode number for /dev/tty under all circumstances. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00211.html - Fix handling of PATH search in execlp and other calls to honor mount flags. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00119.html - Remove a debug message accidentally printed to the terminal window if an application calls fcntl(F_SETFL) erroneously. - Two regressions in 1.7.34 acl(SETACL, ...): - SETACL overwrote the incoming acltent_t array for bookkeeping purposes while iterating over its entries. This broke reusing the acl in the calling application (e.g. setfacl). Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00304.html - SETACL accidentally missed to grant owner FILE_WRITE_ATTRIBUTES access. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00457.html - 64 bit: Export forgotten symbol __mempcpy. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00394.html - 64 bit: Avoid misbehaviour in signal mask computation. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00665.html - Avoid data loss on non-blocking pipes after switching back to blocking. Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00575.html To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer 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
Re: Very slow Cygwin startup on Windows 7
Corinna Vinschen writes: > On Feb 24 14:46, Dennis Hagarty (dehagart) wrote: >> Hi, >> >> With Roger's very patient help, I was able to get ADInsight capturing >> information. >> >> I did a run with the original dll under 32 bit Cygwin running a 32 bit >> program (echo). >> >> Output and all possible reports (in html) from the tool are here: >> https://dl.dropboxusercontent.com/u/33069639/ADInsight.tar.gz >> >> This 32 bit version is the original slower version (takes a few mins >> to open a window): CYGWIN_NT-6.1-WOW DEHAGART-WS02 1.7.34(0.285/5/3) >> 2015-02-04 12:12 i686 Cygwin >> >> So I downloaded the snapshot DLL for 32 bits and did it again: >> CYGWIN_NT-6.1-WOW DEHAGART-WS02 1.7.35s(0.286/5/3) 20150223 21:02:38 >> i686 Cygwin >> >> But this time I wasn't able to get any output on the ADInsight >> (scratches head) > > Perfectly normal. When fetching group info, it does not request any > LDAP info now. In fact, a single LsaLookupSids call for all groups > in your token is all that's required now :) > > > Corinna I was having slow slow Cygwin startups the last bit of time, then I read something about using cygserv since that caches something. (I know, very imprecise, sorry) Anyway, grabbed cygserv, started it. Now cygwin starts almost instantly again. Might not be what you are talking about, didn't read back through all these messages. Just my 2 cents. Dave -- 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: Very slow Cygwin startup on Windows 7
On Feb 25 09:04, J. David Boyd wrote: > Corinna Vinschen writes: > > > On Feb 24 14:46, Dennis Hagarty (dehagart) wrote: > >> Hi, > >> > >> With Roger's very patient help, I was able to get ADInsight capturing > >> information. > >> > >> I did a run with the original dll under 32 bit Cygwin running a 32 bit > >> program (echo). > >> > >> Output and all possible reports (in html) from the tool are here: > >> https://dl.dropboxusercontent.com/u/33069639/ADInsight.tar.gz > >> > >> This 32 bit version is the original slower version (takes a few mins > >> to open a window): CYGWIN_NT-6.1-WOW DEHAGART-WS02 1.7.34(0.285/5/3) > >> 2015-02-04 12:12 i686 Cygwin > >> > >> So I downloaded the snapshot DLL for 32 bits and did it again: > >> CYGWIN_NT-6.1-WOW DEHAGART-WS02 1.7.35s(0.286/5/3) 20150223 21:02:38 > >> i686 Cygwin > >> > >> But this time I wasn't able to get any output on the ADInsight > >> (scratches head) > > > > Perfectly normal. When fetching group info, it does not request any > > LDAP info now. In fact, a single LsaLookupSids call for all groups > > in your token is all that's required now :) > > > > > > Corinna > > I was having slow slow Cygwin startups the last bit of time, then I read > something about using cygserv since that caches something. (I know, very > imprecise, sorry) > > Anyway, grabbed cygserv, started it. Now cygwin starts almost instantly > again. Might not be what you are talking about, didn't read back through all > these messages. Just my 2 cents. Is not what I'm talking about. Try the 1.7.35-0.4 test release without cygserver. It should be noticably faster now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHDuchEHMZB.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 2:01 AM, Corinna Vinschen wrote: > > > - Group "None" is a local group and changing to None is not such a bright > idea for domain users. "Domain Users" may be better here, Since the permissions on files in these directories give zero permissions to the group, does it really matter? It could be Administrators or anything else other than the group with the same name as your user and give the same effect, right? > - Group "None" is a localized group, called, e.g. "Kein" in (really > really terrible) german. Maybe that should be mentioned. Same for > "Domain Users", of course. There’s a homophone in English, “kine,” an archaic word for “cattle.” :) -- 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: Cannot change permission of /var/empty
Andrey, your command, "setfacl -b", helped me fix the file permission issue described below: On Tue, Feb 24, 2015 at 7:38 PM, Andrey Repin wrote: > Greetings, Mirko Vukovic! > >> (Cygwin64, Windows 7, cygcheck attached - with some site details omitted) > >> I updated cygwin64 yesterday, and sshd stopped working. I reinstalled >> cygwin64, configured sshd, but it is still failing. > >> The message in /var/log/sshd.log is: > >> /var/empty must be owned by root and not group or world-writable. > >> I tried fixing the permissions (started shell as administrator) but I >> cannot change the group permission via chmod g-w. I don't get any >> error messages. Here are the permissions for /var/empty (some details >> elided): > >>>ls -ld /var/empty >> drwxr-xr--+ 1 MACHINE+cyg_server Administrators 0 Feb 24 16:12 /var/empty/ > >> I am member of the administrators group on my machine. The cyg_server >> and sshd users look ok. > >> Any thoughts on why I cannot change the permission? > > setfacl -b > Or just remove it altogether. > > > -- > WBR, > Andrey Repin (anrdae...@yandex.ru) 25.02.2015, <03:37> > > Sorry for my terrible english... > Your English was more than adequate for this job :-) Mirko -- 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: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 07:52, Warren Young wrote: > On Feb 25, 2015, at 2:01 AM, Corinna Vinschen > wrote: > > - Group "None" is a local group and changing to None is not such a bright > > idea for domain users. "Domain Users" may be better here, > > Since the permissions on files in these directories give zero > permissions to the group, does it really matter? It could be > Administrators or anything else other than the group with the same > name as your user and give the same effect, right? Sure, but... > > - Group "None" is a localized group, called, e.g. "Kein" in (really > > really terrible) german. Maybe that should be mentioned. Same for > > "Domain Users", of course. > > There’s a homophone in English, “kine,” an archaic word for “cattle.” :) ...the localization problem still exists. What about chgrp `id -g'? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqqrvGJiMjH.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 8:07 AM, Corinna Vinschen wrote: > > What about chgrp `id -g’? That does exactly what you *don’t* want here: $ ls -l id* -rw--- 1 Warren None 1.7K Feb 25 08:12 id_rsa -rw--- 1 Warren None 398 Feb 25 08:12 id_rsa.pub $ chgrp `id -g` id* $ ls -l id* -rw-rw 1 Warren Warren 1.7K Feb 25 08:12 id_rsa -rw-rw 1 Warren Warren 398 Feb 25 08:12 id_rsa.pub How about this uglier alternative? $ chgrp `getent group 513 | cut -f1 -d:` ~/.ssh/* “None” has one of the well-known SIDs, doesn’t it? -- 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: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 8:17 AM, Warren Young wrote: > > “None” has one of the well-known SIDs, doesn’t it? On second thought, “chgrp 513 ~/.ssh/*” seems to work here. Is that portable? -- 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: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 08:17, Warren Young wrote: > On Feb 25, 2015, at 8:07 AM, Corinna Vinschen > wrote: > > > > What about chgrp `id -g’? > > That does exactly what you *don’t* want here: > > $ ls -l id* > -rw--- 1 Warren None 1.7K Feb 25 08:12 id_rsa > -rw--- 1 Warren None 398 Feb 25 08:12 id_rsa.pub > > $ chgrp `id -g` id* > $ ls -l id* > -rw-rw 1 Warren Warren 1.7K Feb 25 08:12 id_rsa > -rw-rw 1 Warren Warren 398 Feb 25 08:12 id_rsa.pub Hang on, how come your group is your user account? That's certainly not correct and it's certainly not the default, neither with SAM accounts, nor with domain accounts. Is that something set in your passwd/group files? If so, change it. > How about this uglier alternative? > > $ chgrp `getent group 513 | cut -f1 -d:` ~/.ssh/* > > “None” has one of the well-known SIDs, doesn’t it? No. None is a "real" group account with the same SID as your machine, plus the attached RID 513. The gid under the new regime would be... $ getent group None $COMPUTERNAME+None nutty81+None:S-1-5-21-3229976424-329291882-2774727752-513:197121: 197121 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcybDwMEHTD.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 08:20, Warren Young wrote: > On Feb 25, 2015, at 8:17 AM, Warren Young wrote: > > > > “None” has one of the well-known SIDs, doesn’t it? > > On second thought, “chgrp 513 ~/.ssh/*” seems to work here. Is that portable? No. You're still using an old group file apparently. Se my other mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_iBFWdKzDH.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 8:23 AM, Corinna Vinschen wrote: > >> $ chgrp `id -g` id* >> $ ls -l id* >> -rw-rw 1 Warren Warren 1.7K Feb 25 08:12 id_rsa >> -rw-rw 1 Warren Warren 398 Feb 25 08:12 id_rsa.pub > > Hang on, how come your group is your user account? That's certainly > not correct and it's certainly not the default, neither with SAM > accounts, nor with domain accounts. Is that something set in your > passwd/group files? If so, change it. I’m using the new SAM support, only. This is how Microsoft configured this Windows 10 VM. I haven’t made any local user admin type changes, except to create a second account for testing. I get this from id(1): $ id uid=1000(Warren) gid=11000(Warren) groups=11000(Warren) …etc. This is why my ~/.ssh contents were getting set to mode 660, and why I had to chgrp None them to fix it. -- 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
gid doesn't display correctly on SAMBA share using AD
Using the latest cygwin: $ cygcheck -c cygwin Cygwin Package Information Package VersionStatus cygwin 1.7.34-6 OK I've asked my admin to update the uidNumber and gidNumber in AD. He has done so: DistinguishedName : CN=build,OU=GroupAccounts,OU=Users,OU=Cambridge,DC=iscinternal,DC=com Enabled : True gidNumber : 999 GivenName : build Name : build ObjectClass : user ObjectGUID: 0901b540-b044-437f-a167-53e1453eab94 SamAccountName: build SID : S-1-5-21-112145844-1872675854-1690816760-17189 Surname : uidNumber : 56191 UserPrincipalName : bu...@iscinternal.com The username displays correctly, but the group name does not: $ ls -la foo -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo And this is confirmed by running getent: $ getent passwd build build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash $ getent passwd group I've read https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos 'til I'm blue in the face, and I think this should work. What am I missing? How can I debug? -- -Len -- 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: gid doesn't display correctly on SAMBA share using AD
On Feb 25 11:01, Len Giambrone wrote: > Using the latest cygwin: > > $ cygcheck -c cygwin > Cygwin Package Information > Package VersionStatus > cygwin 1.7.34-6 OK > > I've asked my admin to update the uidNumber and gidNumber in AD. He has > done so: > > DistinguishedName : > CN=build,OU=GroupAccounts,OU=Users,OU=Cambridge,DC=iscinternal,DC=com > > Enabled : True > > gidNumber : 999 > > GivenName : build > > Name : build > > ObjectClass : user > > ObjectGUID: 0901b540-b044-437f-a167-53e1453eab94 > > SamAccountName: build > > SID : S-1-5-21-112145844-1872675854-1690816760-17189 > > Surname : > > uidNumber : 56191 > > UserPrincipalName : bu...@iscinternal.com > > > The username displays correctly, but the group name does not: > > $ ls -la foo > -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo > > And this is confirmed by running getent: > > $ getent passwd build > build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash > > $ getent passwd group > > I've read > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos > 'til I'm blue in the face, and I think this should work. > What am I missing? How can I debug? If your admin changed your user account to have a gidNumber 999 only, then that won't help, Consider: Cygwin tries to find a group with gidNumber set to 999. How is it supposed to evaluate the right gidNumber value from some arbitrary user account? What Cygwin needs to get the right connection between a Windows group and a gidNumber value is that the *group* entry in AD itself has the gidNumber set to the right value. I don't know if that's really the problem in your case, but that seems the most likely. Please report back. I'm excited that I'm not the only one interested in getting this connection between unix and windows ids working :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpc9HBXomu7n.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 08:55, Warren Young wrote: > On Feb 25, 2015, at 8:23 AM, Corinna Vinschen > wrote: > > > >> $ chgrp `id -g` id* > >> $ ls -l id* > >> -rw-rw 1 Warren Warren 1.7K Feb 25 08:12 id_rsa > >> -rw-rw 1 Warren Warren 398 Feb 25 08:12 id_rsa.pub > > > > Hang on, how come your group is your user account? That's certainly > > not correct and it's certainly not the default, neither with SAM > > accounts, nor with domain accounts. Is that something set in your > > passwd/group files? If so, change it. > > I’m using the new SAM support, only. > > This is how Microsoft configured this Windows 10 VM. I haven’t made > any local user admin type changes, except to create a second account > for testing. > > I get this from id(1): > > $ id > uid=1000(Warren) gid=11000(Warren) groups=11000(Warren) …etc. Darn. Did you set this up with a "Microsoft Account"? If so, then something's not working as expected. There's code in Cygwin which converts your primary group in your user token to the group "Users" in this scenario to avoid this very problem. But somehow this code doesn't kick in in your case and it would be obviously interesdting to know why. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSZ454C8Z8W.pgp Description: PGP signature
tcflush bug?
While debugging a clisp problem, I encountered what I think is a bug in
Cygwin's tcflush. Here's an STC:
$ cat test_tcflush.c
#include
#include
#include
#include
int
main ()
{
if (tcflush (0, TCIFLUSH) == -1)
fprintf (stderr, "Can't flush standard input: %s\n", strerror (errno));
return 0;
}
$ gcc test_tcflush.c -o test_tcflush
$ ./test_tcflush.exe
Can't flush standard input: Resource temporarily unavailable
Am I misunderstanding how this should work, or is this a bug?
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: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 17:21, Corinna Vinschen wrote: > On Feb 25 08:55, Warren Young wrote: > > On Feb 25, 2015, at 8:23 AM, Corinna Vinschen > > wrote: > > > > > >> $ chgrp `id -g` id* > > >> $ ls -l id* > > >> -rw-rw 1 Warren Warren 1.7K Feb 25 08:12 id_rsa > > >> -rw-rw 1 Warren Warren 398 Feb 25 08:12 id_rsa.pub > > > > > > Hang on, how come your group is your user account? That's certainly > > > not correct and it's certainly not the default, neither with SAM > > > accounts, nor with domain accounts. Is that something set in your > > > passwd/group files? If so, change it. > > > > I’m using the new SAM support, only. > > > > This is how Microsoft configured this Windows 10 VM. I haven’t made > > any local user admin type changes, except to create a second account > > for testing. > > > > I get this from id(1): > > > > $ id > > uid=1000(Warren) gid=11000(Warren) groups=11000(Warren) …etc. Btw., the uid and gid values are wrong. You *are* using passwd and group files, otherwise you would have much bigger uid/gid values. RID 1000 should result in uid 197608. Please either remove the files, or change your /etc/nsswitch.conf file to passwd: db group: db > Darn. Did you set this up with a "Microsoft Account"? If so, then > something's not working as expected. There's code in Cygwin which > converts your primary group in your user token to the group "Users" in > this scenario to avoid this very problem. > > But somehow this code doesn't kick in in your case and it would be > obviously interesdting to know why. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzr7WqGItfh.pgp Description: PGP signature
Re: tcflush bug?
On Feb 25 11:24, Ken Brown wrote:
> While debugging a clisp problem, I encountered what I think is a bug in
> Cygwin's tcflush. Here's an STC:
>
> $ cat test_tcflush.c
> #include
> #include
> #include
> #include
>
> int
> main ()
> {
> if (tcflush (0, TCIFLUSH) == -1)
> fprintf (stderr, "Can't flush standard input: %s\n", strerror (errno));
> return 0;
> }
>
> $ gcc test_tcflush.c -o test_tcflush
>
> $ ./test_tcflush.exe
> Can't flush standard input: Resource temporarily unavailable
>
> Am I misunderstanding how this should work, or is this a bug?
A bug in the pty code (observe this working correctly in a Windows
console). I applied a fix to CVS. Do you need a snapshot?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpLHKDtN6TUE.pgp
Description: PGP signature
Re: gid doesn't display correctly on SAMBA share using AD
On 02/25/2015 11:18 AM, Corinna Vinschen wrote: On Feb 25 11:01, Len Giambrone wrote: Using the latest cygwin: $ cygcheck -c cygwin Cygwin Package Information Package VersionStatus cygwin 1.7.34-6 OK I've asked my admin to update the uidNumber and gidNumber in AD. He has done so: DistinguishedName : CN=build,OU=GroupAccounts,OU=Users,OU=Cambridge,DC=iscinternal,DC=com Enabled : True gidNumber : 999 GivenName : build Name : build ObjectClass : user ObjectGUID: 0901b540-b044-437f-a167-53e1453eab94 SamAccountName: build SID : S-1-5-21-112145844-1872675854-1690816760-17189 Surname : uidNumber : 56191 UserPrincipalName : bu...@iscinternal.com The username displays correctly, but the group name does not: $ ls -la foo -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo And this is confirmed by running getent: $ getent passwd build build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash $ getent passwd group I've read https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos 'til I'm blue in the face, and I think this should work. What am I missing? How can I debug? If your admin changed your user account to have a gidNumber 999 only, then that won't help, Consider: Cygwin tries to find a group with gidNumber set to 999. How is it supposed to evaluate the right gidNumber value from some arbitrary user account? What Cygwin needs to get the right connection between a Windows group and a gidNumber value is that the *group* entry in AD itself has the gidNumber set to the right value. I don't know if that's really the problem in your case, but that seems the most likely. Please report back. I'm excited that I'm not the only one interested in getting this connection between unix and windows ids working :) It worked. :) Now I just have to persuade my admin to populate uidNumber and gidNumber for all our current and new users... Corinna -- -Len -- 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: tcflush bug?
On 2/25/2015 11:48 AM, Corinna Vinschen wrote:
On Feb 25 11:24, Ken Brown wrote:
While debugging a clisp problem, I encountered what I think is a bug in
Cygwin's tcflush. Here's an STC:
$ cat test_tcflush.c
#include
#include
#include
#include
int
main ()
{
if (tcflush (0, TCIFLUSH) == -1)
fprintf (stderr, "Can't flush standard input: %s\n", strerror (errno));
return 0;
}
$ gcc test_tcflush.c -o test_tcflush
$ ./test_tcflush.exe
Can't flush standard input: Resource temporarily unavailable
Am I misunderstanding how this should work, or is this a bug?
A bug in the pty code (observe this working correctly in a Windows
console). I applied a fix to CVS. Do you need a snapshot?
Thanks for the quick fix! No, I don't need a snapshot.
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
2015-02-25 13:51 GMT+01:00 Corinna Vinschen: > Another important change in this release is a change to chmod. As many > of you experienced 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 secondary groups and users in the ACL have more permissions > than the primary group. If so, the permissions of the secondary users > and groups will be reduced according to the mask given by the new > primary group permissions. I.e, chmod 600 will remove all permissions > from the primary group as well as all secondary user and group entries > in the ACL. I have problems running screen on my pc. When I start it, it complains about the mode of the temporary directory. "Directory /tmp/uscreens/S-Frank must have mode 700." With 1.7.35-0.3 I could not chmod the directory manually. I just upgraded to 1.7.35-0.4 and now I can manually chmod the directory to 700 and start screen again. But IFAIK previously (not sure when) screen was able to chmod the directory itself, but now not anymore. Regards, Frank -- 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: tcflush bug?
On 2/25/2015 11:54 AM, Ken Brown wrote:
On 2/25/2015 11:48 AM, Corinna Vinschen wrote:
On Feb 25 11:24, Ken Brown wrote:
While debugging a clisp problem, I encountered what I think is a bug
in Cygwin's tcflush. Here's an STC:
$ cat test_tcflush.c
#include
#include
#include
#include
int
main ()
{
if (tcflush (0, TCIFLUSH) == -1)
fprintf (stderr, "Can't flush standard input: %s\n", strerror
(errno));
return 0;
}
$ gcc test_tcflush.c -o test_tcflush
$ ./test_tcflush.exe
Can't flush standard input: Resource temporarily unavailable
Am I misunderstanding how this should work, or is this a bug?
A bug in the pty code (observe this working correctly in a Windows
console). I applied a fix to CVS. Do you need a snapshot?
Thanks for the quick fix! No, I don't need a snapshot.
And I can confirm that it fixes the problem (and the original clisp
problem).
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: gid doesn't display correctly on SAMBA share using AD
On Feb 25 11:51, Len Giambrone wrote: > On 02/25/2015 11:18 AM, Corinna Vinschen wrote: > >On Feb 25 11:01, Len Giambrone wrote: > >>[...] > >>The username displays correctly, but the group name does not: > >> > >>$ ls -la foo > >>-rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo > >> > >>And this is confirmed by running getent: > >> > >>$ getent passwd build > >>build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash > >> > >>$ getent passwd group > >> > >>I've read > >>https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos > >>'til I'm blue in the face, and I think this should work. > >>What am I missing? How can I debug? > >If your admin changed your user account to have a gidNumber 999 only, > >then that won't help, Consider: Cygwin tries to find a group with > >gidNumber set to 999. How is it supposed to evaluate the right > >gidNumber value from some arbitrary user account? > > > >What Cygwin needs to get the right connection between a Windows group > >and a gidNumber value is that the *group* entry in AD itself has the > >gidNumber set to the right value. > > > >I don't know if that's really the problem in your case, but that seems > >the most likely. > > > >Please report back. I'm excited that I'm not the only one interested > >in getting this connection between unix and windows ids working :) > > It worked. :) Now I just have to persuade my admin to populate uidNumber > and gidNumber for all our current and new users... I'm glad to read that. Thanks for your feedback! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4ZGSOTmpW3.pgp Description: PGP signature
Re: tcflush bug?
On Feb 25 12:06, Ken Brown wrote:
> On 2/25/2015 11:54 AM, Ken Brown wrote:
> >On 2/25/2015 11:48 AM, Corinna Vinschen wrote:
> >>On Feb 25 11:24, Ken Brown wrote:
> >>>While debugging a clisp problem, I encountered what I think is a bug
> >>>in Cygwin's tcflush. Here's an STC:
> >>>
> >>>$ cat test_tcflush.c
> >>>#include
> >>>#include
> >>>#include
> >>>#include
> >>>
> >>>int
> >>>main ()
> >>>{
> >>> if (tcflush (0, TCIFLUSH) == -1)
> >>> fprintf (stderr, "Can't flush standard input: %s\n", strerror
> >>>(errno));
> >>> return 0;
> >>>}
> >>>
> >>>$ gcc test_tcflush.c -o test_tcflush
> >>>
> >>>$ ./test_tcflush.exe
> >>>Can't flush standard input: Resource temporarily unavailable
> >>>
> >>>Am I misunderstanding how this should work, or is this a bug?
> >>
> >>A bug in the pty code (observe this working correctly in a Windows
> >>console). I applied a fix to CVS. Do you need a snapshot?
> >
> >Thanks for the quick fix! No, I don't need a snapshot.
>
> And I can confirm that it fixes the problem (and the original clisp
> problem).
Yay!
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpalutu2edJO.pgp
Description: PGP signature
Re: gid doesn't display correctly on SAMBA share using AD
On 02/25/2015 12:20 PM, Corinna Vinschen wrote: On Feb 25 11:51, Len Giambrone wrote: On 02/25/2015 11:18 AM, Corinna Vinschen wrote: On Feb 25 11:01, Len Giambrone wrote: [...] The username displays correctly, but the group name does not: $ ls -la foo -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo And this is confirmed by running getent: $ getent passwd build build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash $ getent passwd group I've read https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos 'til I'm blue in the face, and I think this should work. What am I missing? How can I debug? If your admin changed your user account to have a gidNumber 999 only, then that won't help, Consider: Cygwin tries to find a group with gidNumber set to 999. How is it supposed to evaluate the right gidNumber value from some arbitrary user account? What Cygwin needs to get the right connection between a Windows group and a gidNumber value is that the *group* entry in AD itself has the gidNumber set to the right value. I don't know if that's really the problem in your case, but that seems the most likely. Please report back. I'm excited that I'm not the only one interested in getting this connection between unix and windows ids working :) It worked. :) Now I just have to persuade my admin to populate uidNumber and gidNumber for all our current and new users... I'm glad to read that. Thanks for your feedback! If I can't get my admin to cooperate, then I have to resort to using mkpasswd/mkgroup -U. But this gives output like this: $ ls -la foo -rw-rw-r-- 1 Unix_User+build Unix_Group+releng 0 Feb 25 10:52 foo Is that expected? (The Unix_User+/Unix_Group+ prefix). Corinna -- -Len -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
On Feb 25 17:34, Frank Fesevur wrote: > 2015-02-25 13:51 GMT+01:00 Corinna Vinschen: > > Another important change in this release is a change to chmod. As many > > of you experienced 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 secondary groups and users in the ACL have more permissions > > than the primary group. If so, the permissions of the secondary users > > and groups will be reduced according to the mask given by the new > > primary group permissions. I.e, chmod 600 will remove all permissions > > from the primary group as well as all secondary user and group entries > > in the ACL. > > I have problems running screen on my pc. When I start it, it complains > about the mode of the temporary directory. > "Directory /tmp/uscreens/S-Frank must have mode 700." > > With 1.7.35-0.3 I could not chmod the directory manually. I just > upgraded to 1.7.35-0.4 and now I can manually chmod the directory to > 700 and start screen again. > > But IFAIK previously (not sure when) screen was able to chmod the > directory itself, but now not anymore. There's no difference in chmod whether called from screen or manually from the shell. It's always the same call to chmod(2). I don't know what's going on in screen there, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9v0Au_zj7L.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 9:21 AM, Corinna Vinschen wrote:
>
> Did you set this up with a "Microsoft Account”?
Yes.
> Btw., the uid and gid values are wrong. You *are* using passwd and
> group files, otherwise you would have much bigger uid/gid values.
Oooky. I thought I just had to remove /etc/{passwd,group}, so that the
default “files db” settings would fail to find files and fall back to db.
I’ve forced db in nsswitch.conf and am now getting the expected high ID values
and Users group:
$ id
uid=197608(Warren) gid=545(Users) … etc.
So, I suppose the question is, why would I get group=Warren when there are no
/etc files and nsswitch.conf is empty?
I’m going to treat that as a side issue and apply your suggested modification
to the chgrp hack.
--
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: gid doesn't display correctly on SAMBA share using AD
On Feb 25 12:26, Len Giambrone wrote: > > On 02/25/2015 12:20 PM, Corinna Vinschen wrote: > >On Feb 25 11:51, Len Giambrone wrote: > >>On 02/25/2015 11:18 AM, Corinna Vinschen wrote: > >>>On Feb 25 11:01, Len Giambrone wrote: > [...] > The username displays correctly, but the group name does not: > > $ ls -la foo > -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo > > And this is confirmed by running getent: > > $ getent passwd build > build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash > > $ getent passwd group > > I've read > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos > 'til I'm blue in the face, and I think this should work. > What am I missing? How can I debug? > >>>If your admin changed your user account to have a gidNumber 999 only, > >>>then that won't help, Consider: Cygwin tries to find a group with > >>>gidNumber set to 999. How is it supposed to evaluate the right > >>>gidNumber value from some arbitrary user account? > >>> > >>>What Cygwin needs to get the right connection between a Windows group > >>>and a gidNumber value is that the *group* entry in AD itself has the > >>>gidNumber set to the right value. > >>> > >>>I don't know if that's really the problem in your case, but that seems > >>>the most likely. > >>> > >>>Please report back. I'm excited that I'm not the only one interested > >>>in getting this connection between unix and windows ids working :) > >>It worked. :) Now I just have to persuade my admin to populate uidNumber > >>and gidNumber for all our current and new users... > >I'm glad to read that. Thanks for your feedback! > > If I can't get my admin to cooperate, then I have to resort to using > mkpasswd/mkgroup -U. But this gives output like this: > > $ ls -la foo > -rw-rw-r-- 1 Unix_User+build Unix_Group+releng 0 Feb 25 10:52 foo > > Is that expected? (The Unix_User+/Unix_Group+ prefix). Yes, that's expected. After all, they are users different from your Windows account, see the SIDs. If you don't want the prefix, you can still override this by manually dropping the prefixes, along the lines of what you could already do in the former implementation. Should be a last resort, of course. The other, better way not restricted to Cygwin is to install Samba's winbind. It just doesn't help for existing UNIX accounts, afaics. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4jBgYH_dac.pgp Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 10:32, Warren Young wrote:
> On Feb 25, 2015, at 9:21 AM, Corinna Vinschen
> wrote:
> >
> > Did you set this up with a "Microsoft Account”?
>
> Yes.
>
> > Btw., the uid and gid values are wrong. You *are* using passwd and
> > group files, otherwise you would have much bigger uid/gid values.
>
> Oooky. I thought I just had to remove /etc/{passwd,group}, so
> that the default “files db” settings would fail to find files and fall
> back to db.
It does... if you stopped and restarted your Cygwin processes afterwards,
or in a new session if you start this one afterwards. If not, the
existing processes will happily use what they have cached.
If you remove nsswitch.conf and passwd and group, you should still
see uid=197608(Warren) gid=545(Users) in id output now.
If not, I'll be puzzled no end and we will have to debug that. That's a
threat, if you didn't notice ;)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpSHeA9Iee_S.pgp
Description: PGP signature
Re: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25, 2015, at 10:47 AM, Corinna Vinschen
wrote:
>
> On Feb 25 10:32, Warren Young wrote:
>> On Feb 25, 2015, at 9:21 AM, Corinna Vinschen
>> wrote:
>>>
>>> Did you set this up with a "Microsoft Account”?
>>
>> Yes.
>>
>>> Btw., the uid and gid values are wrong. You *are* using passwd and
>>> group files, otherwise you would have much bigger uid/gid values.
>>
>> Oooky. I thought I just had to remove /etc/{passwd,group}, so
>> that the default “files db” settings would fail to find files and fall
>> back to db.
>
> It does... if you stopped and restarted your Cygwin processes afterwards,
I was sure I had. I don’t run any cygrunsrv processes on that VM, so I only
have to restart MinTTY to make sure Cygwin cleanly reloads.
Nevertheless, moving nsswitch.conf out of the way, restarting, and re-running
id(1) continues to result in a high UID.
I don’t know what was going on earlier, but the ghost has evaporated now.
The FAQ item change is checked in now, by the way. You might want to give the
new text a sanity check.
--
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: Unexpected EINVAL from pthread_join
On Feb 24 22:20, Corinna Vinschen wrote: > Hi Lasse, > > On Feb 24 20:37, Lasse Collin wrote: > > On 2015-02-24 Corinna Vinschen wrote: > > > On Feb 24 15:54, Lasse Collin wrote: > > > > Many other pthread functions are similar in sense that they must > > > > never return EINTR. A bug similar to the one in pthread::join exist > > > > in pthread_mutex::lock. If SA_RESTART isn't used, signals can make > > > > multiple threads get a lock on the same mutex at the same time. A > > > > test program is attached. Adding cw_sig_restart to the cygwait call > > > > in pthread_mutex::lock fixes this. > > > > > > Can you collect the info which functions are affected so that lazy me > > > just has to apply the cw_sig_restart patches in bulk? > > > > I grepped for cygwait uses earlier but I don't understand the code well > > enough to be sure about anything. The following is pretty much > > guessing, but hopefully there's something useful still. > > > > These look the most suspicious to me, possibly needing cw_sig_restart: > > > > thread.h fast_mutex::lock > > fhandler_tape.cc fhandler_dev_tape::_lock FYI, I fixed these plus pthread_mutex::lock. > > When looking for things needing cw_sig_restart, I started to wonder if > > cw_sig_eintr is used properly in all cases. Often the caller of > > cygwait + cw_sig_eintr will also conditionally call > > _my_tls.call_signal_handler, but the following functions don't. The > > comment in handle_sigsuspend makes me think that this may be a false > > alarm but I mention these just in case. > > > > exceptions.cc handle_sigsuspend This works as desired, afaics. > > posix_ipc.cc ipc_mutex_lock > > signal.cc clock_nanosleep > > signal.cc sigwaitinfo > > thread.cc pthread_cond::wait > > thread.cc semaphore::_timedwait > > thread.cc semaphore::_wait > [...] > > In the following functions the situation is kind of reversed. Those > > functions call _my_tls.call_signal_handler even though cw_sig_eintr > > wasn't specified. cygwait will already have called the signal handler > > since cw_sig has been specified via cygwait(DWORD). So I guess in these > > functions the signal handler might get called twice. > > > > fhandler_dsp.cc fhandler_dev_dsp::Audio_out::waitforspace > > fhandler_dsp.cc fhandler_dev_dsp::Audio_in::waitfordata I'm still mulling over the rest of your list... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0u1I_oAIMO.pgp Description: PGP signature
Re: gid doesn't display correctly on SAMBA share using AD
On 02/25/2015 12:34 PM, Corinna Vinschen wrote: On Feb 25 12:26, Len Giambrone wrote: On 02/25/2015 12:20 PM, Corinna Vinschen wrote: On Feb 25 11:51, Len Giambrone wrote: On 02/25/2015 11:18 AM, Corinna Vinschen wrote: On Feb 25 11:01, Len Giambrone wrote: [...] The username displays correctly, but the group name does not: $ ls -la foo -rw-rw-r-- 1 build Unix_Group+999 0 Feb 25 10:52 foo And this is confirmed by running getent: $ getent passwd build build:*:1065765:1049089:U-ISCINTERNAL\build,S-1-5-21-112145844-1872675854-1690816760-17189:/home/build:/bin/bash $ getent passwd group I've read https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-gecos 'til I'm blue in the face, and I think this should work. What am I missing? How can I debug? If your admin changed your user account to have a gidNumber 999 only, then that won't help, Consider: Cygwin tries to find a group with gidNumber set to 999. How is it supposed to evaluate the right gidNumber value from some arbitrary user account? What Cygwin needs to get the right connection between a Windows group and a gidNumber value is that the *group* entry in AD itself has the gidNumber set to the right value. I don't know if that's really the problem in your case, but that seems the most likely. Please report back. I'm excited that I'm not the only one interested in getting this connection between unix and windows ids working :) It worked. :) Now I just have to persuade my admin to populate uidNumber and gidNumber for all our current and new users... I'm glad to read that. Thanks for your feedback! If I can't get my admin to cooperate, then I have to resort to using mkpasswd/mkgroup -U. But this gives output like this: $ ls -la foo -rw-rw-r-- 1 Unix_User+build Unix_Group+releng 0 Feb 25 10:52 foo Is that expected? (The Unix_User+/Unix_Group+ prefix). Yes, that's expected. After all, they are users different from your Windows account, see the SIDs. That's what I thought. If you don't want the prefix, you can still override this by manually dropping the prefixes, along the lines of what you could already do in the former implementation. Should be a last resort, of course. I actually tried that; I removed the Unix_User/Group+ prefix from the passwd entry to see if it worked. It did, but then I couldn't ssh in as that user: build@wx64lg /etc $ cat /etc/passwd lgiambro:*:4278246287:9:,S-1-22-1-56207:: build@wx64lg /etc $ cat /etc/group releng:S-1-22-2-999:4278191079: lgiambro@ubuntu ~/perforce/dev/latest/build/tools $ ssh -o PubkeyAuthentication=no wx64lg lgiambro@wx64lg's password: Connection to wx64lg closed by remote host. Connection to wx64lg closed. The other, better way not restricted to Cygwin is to install Samba's winbind. We are running winbind. It just doesn't help for existing UNIX accounts, afaics. I don't know how winbind works. If it doesn't work with existing UNIX accounts, then when _would_ it have an effect? Corinna -- -Len -- 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: slow startup after upgrade
Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015: > On Feb 24 16:03, q2t2hzm...@snkmail.com wrote: > > Corinna Vinschen corinna-cygwin-at-cygwin.com |cygwin_ml_nodigest| wrote > > at 22:13 +0100 on Feb 24, 2015: > > > Hi Roger, > > > > > > On Feb 24 19:55, Roger Orr wrote: > > > > Hello Corinna, > > > > It seems slightly faster than the previous patch and I've not noticed > > a > > > > downside yet. > > > > > > > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 > > i686 > > > > Cygwin: > > > > > > > > ~37ms to run echo.exe from Windows command prompt > > > > ~60ms to run .\id.exe -a from Windows command prompt > > > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 > > i686 > > > > Cygwin: > > > > > > > > ~35ms to run echo.exe from Windows command prompt > > > > ~53ms to run .\id.exe -a from Windows command prompt > > > > > > That's a nice result. > > > > > > However, I don't quite understand this result for the older DLL. > > > Weren't you reporting >4 secs as startup time from 1.7.35?!? > > > > > > On another note: > > > > > > I just uploaded a new developer snapshot (2015-02-24). This snapshot > > > should improve mkpasswd/mkgroup or, generally speaking, enumerating AD > > > accounts, a lot. Can you give it a try? > > > > > > While you're at it, does the new snapshot still stop after 3.5K accounts > > > even though you think there are 8K accounts? If so, I'd be interested > > > to investigate this further. The reason is, while testing my today's > > > performance improvements, I stumbled over a bug in my code which also > > > resulted in enumerating less accounts as desired. So I'm not entirely > > > sure your problem isn't related to a bug either. > > > > That mkpasswd symptom was reported by me > > Really? This is the first time I see your email address on this ML, and > there's no name connected to it, so I don't even know if you're usually > writing under another email address. At least a forename would be nice... Bah... sorry, you should get the name in this response. > > (well, maybe others, too). > > I'm running it again, but it's still very slow, AFAICS. > > It shouldn't. It performs only one LDAP call now per 100 accounts, > If that's still slow in your environment, I don't see any way to > speed this up any further. > > > I'll report > > how long it took when / if it finishes. > > > > New issue with recent snaps: > > > > Running the 20150224 (and *23) snapshot produces the following on Win > > XP (yes, I know) if cygserver is running: > > Sidenote: I'm contemplating to stop supporting XP end of this year. I'm thinking it's either related to XP or _something_ with the particular XP box I'm using (when logged in on the domain, I can't disable many group policy things or temporarily inhibit AV, so it's harder to find/eliminate something to pin blame on - certainly may not be something the latest cygwin is doing when running on XP in a "large" AD domain). I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33 seconds and enumerates all 8016 entries. 37 seconds with the 2/25 snap. And win 7 doesn't get the 'wrong arg.type' error with the same 2/24 cygwin1.dll for whatever reason. > > $ /usr/sbin/syslog-ng -F > > 1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** fatal > > error - Fetching account info from cygserver with wrong arg.type 2 > > Try the snapshot I just uploaded (2015-02-25). I forgot a tiny, but > crucial statement in the code when I changed that code two days ago. > That should be fixed now. > > > tcsh still taking a long time here (also XP - 3+ minutes with > > cygserver running). bash & dash much quicker. > > Works very quickly for me. Problem is, I don't know anything about > your environment. Are you working remote or in an office? How many > groups are in your user token? What is the result of this funny > little statement Dennis created: > > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & > echo !TIME!" On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time stamp That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs running including cygserver. On problematic winxp box: [passwd, group, db_shell: 'files db', 'files db' & /bin/dash] 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec [passwd, group, db_shell: db, db & /bin/dash] 23.51, 27.91, 28.78 sec Any trials using /bin/tcsh without disabling complete.tcsh take "a really long time" (TM)... from minutes with 2/25 snap to 10s of minutes with 1.7.34. I mentioned this in another thread (and strace sometimes showed 5 minute gaps around forks). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Un
Re: slow startup after upgrade
John Hein wrote at 11:15 -0700 on Feb 25, 2015: > Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015: > > On Feb 24 16:03, John Hein wrote: > > > Corinna Vinschen wrote at 22:13 +0100 on Feb 24, 2015: > > > > Hi Roger, > > > > > > > > On Feb 24 19:55, Roger Orr wrote: > > > > > Hello Corinna, > > > > > It seems slightly faster than the previous patch and I've not > noticed a > > > > > downside yet. > > > > > > > > > > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 > i686 > > > > > Cygwin: > > > > > > > > > > ~37ms to run echo.exe from Windows command prompt > > > > > ~60ms to run .\id.exe -a from Windows command prompt > > > > > > > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 > i686 > > > > > Cygwin: > > > > > > > > > > ~35ms to run echo.exe from Windows command prompt > > > > > ~53ms to run .\id.exe -a from Windows command prompt > > > > > > > > That's a nice result. > > > > > > > > However, I don't quite understand this result for the older DLL. > > > > Weren't you reporting >4 secs as startup time from 1.7.35?!? > > > > > > > > On another note: > > > > > > > > I just uploaded a new developer snapshot (2015-02-24). This snapshot > > > > should improve mkpasswd/mkgroup or, generally speaking, enumerating > AD > > > > accounts, a lot. Can you give it a try? > > > > > > > > While you're at it, does the new snapshot still stop after 3.5K > accounts > > > > even though you think there are 8K accounts? If so, I'd be > interested > > > > to investigate this further. The reason is, while testing my today's > > > > performance improvements, I stumbled over a bug in my code which also > > > > resulted in enumerating less accounts as desired. So I'm not > entirely > > > > sure your problem isn't related to a bug either. > > > > > > That mkpasswd symptom was reported by me > > > > Really? This is the first time I see your email address on this ML, and > > there's no name connected to it, so I don't even know if you're usually > > writing under another email address. At least a forename would be nice... > > > Bah... sorry, you should get the name in this response. > > > > > (well, maybe others, too). > > > I'm running it again, but it's still very slow, AFAICS. > > > > It shouldn't. It performs only one LDAP call now per 100 accounts, > > If that's still slow in your environment, I don't see any way to > > speed this up any further. > > > > > I'll report > > > how long it took when / if it finishes. > > > > > > New issue with recent snaps: > > > > > > Running the 20150224 (and *23) snapshot produces the following on Win > > > XP (yes, I know) if cygserver is running: > > > > Sidenote: I'm contemplating to stop supporting XP end of this year. > > I'm thinking it's either related to XP or _something_ with the > particular XP box I'm using (when logged in on the domain, I can't > disable many group policy things or temporarily inhibit AV, so it's > harder to find/eliminate something to pin blame on - certainly may not > be something the latest cygwin is doing when running on XP in a > "large" AD domain). > > I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33 > seconds and enumerates all 8016 entries. 37 seconds with the 2/25 > snap. > > And win 7 doesn't get the 'wrong arg.type' error with the same 2/24 > cygwin1.dll for whatever reason. > > > > > $ /usr/sbin/syslog-ng -F > > > 1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** > fatal error - Fetching account info from cygserver with wrong arg.type 2 > > > > Try the snapshot I just uploaded (2015-02-25). I forgot a tiny, but > > crucial statement in the code when I changed that code two days ago. > > That should be fixed now. > > > > > tcsh still taking a long time here (also XP - 3+ minutes with > > > cygserver running). bash & dash much quicker. > > > > Works very quickly for me. Problem is, I don't know anything about > > your environment. Are you working remote or in an office? How many > > groups are in your user token? What is the result of this funny > > little statement Dennis created: > > > > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" > & echo !TIME!" > > On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time > stamp > > That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs > running including cygserver. > > > On problematic winxp box: > [passwd, group, db_shell: 'files db', 'files db' & /bin/dash] > 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec > > [passwd, group, db_shell: db, db & /bin/dash] > 23.51, 27.91, 28.78 sec > > Any trials using /bin/tcsh without disabling complete.tcsh take "a > really long time" (TM)..
chmod: creator owner victimized? ... (1.7.35-0.4)
Hi Corinna, Ref: https://cygwin.com/ml/cygwin/2015-02/msg00798.html - [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4 Something for your list of things to think about ... and do later ;-) For a directory, the 'creator owner' should have sufficient permissions. That is, at least 'full control minus delete'; full control is good. (yes, as far as I can tell) (with respect to setfacl, I made a similar remark) That has changed in 1.7.35-0.4 with respect to chmod ... As result one cannot 'touch' (create) a file in a subdirectory, that has been created using Explorer. Henri - List of commands: using 1.7.35-0.4 - mkdir QL - chmod 755 QL - create QL/dir2 using Explorer - touch QL/dir2/aap < fails @@ uname -a # NON-elevated bash CYGWIN_NT-6.1-WOW Seven 1.7.35(0.286/5/3) 2015-02-25 13:11 i686 Cygwin @@ pwd /drv/e @@ icacls.sh /drv/e E:/ Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(F) CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ mkdir QL @@ icacls.sh /drv/e/QL E:/QL Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(F) < Note: 'F minus delete' will do; F is good CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ chmod 755 QL @@ icacls.sh QL E:/QL Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(RX) < NO, INsufficient in case a subdir is created using Explorer CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ icacls.sh QL/dir2 E:/QL/dir2 Seven\Henri(I)(RX) < dir2 has been created using Explorer CREATOR OWNER (I)(OI)(CI)(IO)(RX) Seven\None (I)(RX) CREATOR GROUP (I)(OI)(CI)(IO)(RX) Everyone (I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files @@ touch QL/dir2/aap touch: cannot touch QL/dir2/aap: Permission denied @@ mkdir QL/dir @@ touch QL/dir/aap @@ icacls.sh QL/dir E:/QL/dir Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(F) CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ - List of commands: using 1.7.35-0.3 < 3, not 4 - mkdir QL - chmod 755 QL 64-@@ uname -a # NON-elevated bash CYGWIN_NT-6.1 Seven 1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin 64-@@ pwd /drv/e 64-@@ mkdir T 64-@@ /opt/home/Henri/bin/icacls.sh T E:/T Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(F) CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files 64-@@ chmod 755 T 64-@@ /opt/home/Henri/bin/icacls.sh T E:/T Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(F) < Ah! CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files 64-@@ = -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
Corinna Vinschen writes: > This release introduces a rewrite of the functions being the main > culprit for the slowness of fetching account information from AD. > There are still a few potential ways to hone the results, but code-wise > there isn't a lot left to do anymore. I'll reply here… I've just tested the latest snapshot (aka the 0.4 release) via VPN. The basic test is starting a mintty from a cmd prompt and have mintty run some program depending on the test. I run two tests, one is just an "echo test" which uses the builtin echo of the shell that mintty just fired up, the other does a "git status". Connected via LAN the echo tests take all under a second now save for a few excursion when I didn't start cygwrunserv that were around 1.5s. The git test takes a bit longer depending on whether I start it on a network share or a local directory, but completes in under 2s. Now, connecting via the VPN and not running cygserv I get 2s for the echo test and 47/42/6 seconds for git status on two different network shares and a local repository (these repositories are all fairly small, just some local configuration stuff). With cygserv running, these times change to 1/49/5/5 seconds (yes, it took two seconds longer on one of the network shares). As it happens, I can force the VPN to connect almost exactly from the other side of the globe, which will produce a long roundtrip time (unless you are having a satellite link in there somewhere or really stupid routing it can't get much worse than that). In this case, with cygserv running I get 15/840/40/85 seconds. Without cygserv, this becomes 39/789/-/95 (I skipped one of the network shares for this test). Again there's one network share that had better performance for the git test without cygserv. Another interesting bit is that the echo test time actually depended on whether the working directory was on a network share (resulting in 39 seconds) or on the local drive (where it only took 26 seconds). So, those changes in the latest snapshot look good from that perspective and the remaining delays, at least with cygserv running are in any case not attributable to the LDAP integration. I don't have an old Cygwin installation o that machine anymore, but the results w/ cygserv on the long latency link match my experience of using that long latency link "for real" about a year ago. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
[ANNOUNCEMENT] Updated: e2fsprogs-1.42.12-1
The following packages have been updated for the Cygwin distribution: * e2fsprogs-1.42.12-1 * libcom_err2-1.42.12-1 * libcom_err-devel-1.42.12-1 * libe2p2-1.42.12-1 * libe2p-devel-1.42.12-1 * libext2fs2-1.42.12-1 * libext2fs-devel-1.42.12-1 * libss2-1.42.12-1 * libss-devel-1.42.12-1 e2fsprogs provide utilities and libraries for working with ext2/3/4 filesystems. This is an update to the latest upstream release: http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.12 -- Yaakov -- 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: gid doesn't display correctly on SAMBA share using AD
On Feb 25 12:55, Len Giambrone wrote: > On 02/25/2015 12:34 PM, Corinna Vinschen wrote: > >On Feb 25 12:26, Len Giambrone wrote: > >>$ ls -la foo > >>-rw-rw-r-- 1 Unix_User+build Unix_Group+releng 0 Feb 25 10:52 foo > >> > >>Is that expected? (The Unix_User+/Unix_Group+ prefix). > >Yes, that's expected. After all, they are users different from your > >Windows account, see the SIDs. > > That's what I thought. > > > If you don't want the prefix, you can > >still override this by manually dropping the prefixes, along the lines > >of what you could already do in the former implementation. Should be a > >last resort, of course. > > I actually tried that; I removed the Unix_User/Group+ prefix from the passwd > entry to see if it worked. > It did, but then I couldn't ssh in as that user: > > build@wx64lg /etc > $ cat /etc/passwd > lgiambro:*:4278246287:9:,S-1-22-1-56207:: > > build@wx64lg /etc > $ cat /etc/group > releng:S-1-22-2-999:4278191079: Oh, wait. That's not good. If you do that you must create *two* entries in /etc/passwd and /etc/group with the same account names, one of them being the Windows account, the other being the UNIX account. The order is important, too. The Windows account must preceed the UNIX account, kind of like this: $ mkpasswd -b -c -l my-unix-machine -U corinna corinna:*:1049577:1049701:U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh Unix_User+corinna:*:4278190580:9:,S-1-22-1-500:: Then remove the Unix_User prefix. It's a bit fragile, that's why other solutions are better, imho. > > The other, better way not restricted to Cygwin > >is to install Samba's winbind. > > We are running winbind. > > > It just doesn't help for existing UNIX > >accounts, afaics. > > I don't know how winbind works. If it doesn't work with existing UNIX > accounts, then when _would_ it have an effect? I don't know exactly how winbind works either. AFAIK it gets a range of UNIX uid/gids, e.g 10-20, and then it translates any incoming Windows SID into a Unix uid/gid in that range. These users are handled by winbind, but not any other, already existing users like "root" or, fwiw, any uid/gid outside the range it maintains. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppEWuQway0i.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
On Feb 25 21:02, Achim Gratz wrote: > Corinna Vinschen writes: > > This release introduces a rewrite of the functions being the main > > culprit for the slowness of fetching account information from AD. > > There are still a few potential ways to hone the results, but code-wise > > there isn't a lot left to do anymore. > > I'll reply here… > > I've just tested the latest snapshot (aka the 0.4 release) via VPN. The > basic test is starting a mintty from a cmd prompt and have mintty run > some program depending on the test. I run two tests, one is just an > "echo test" which uses the builtin echo of the shell that mintty just > fired up, the other does a "git status". Connected via LAN the echo > tests take all under a second now save for a few excursion when I didn't > start cygwrunserv that were around 1.5s. The git test takes a bit > longer depending on whether I start it on a network share or a local > directory, but completes in under 2s. > > Now, connecting via the VPN and not running cygserv I get 2s for the > echo test and 47/42/6 seconds for git status on two different network > shares and a local repository (these repositories are all fairly small, > just some local configuration stuff). With cygserv running, these times > change to 1/49/5/5 seconds (yes, it took two seconds longer on one of > the network shares). > > As it happens, I can force the VPN to connect almost exactly from the > other side of the globe, which will produce a long roundtrip time > (unless you are having a satellite link in there somewhere or really > stupid routing it can't get much worse than that). In this case, with > cygserv running I get 15/840/40/85 seconds. Without cygserv, this > becomes 39/789/-/95 (I skipped one of the network shares for this test). > Again there's one network share that had better performance for the git > test without cygserv. Another interesting bit is that the echo test > time actually depended on whether the working directory was on a network > share (resulting in 39 seconds) or on the local drive (where it only > took 26 seconds). > > So, those changes in the latest snapshot look good from that perspective > and the remaining delays, at least with cygserv running are in any case > not attributable to the LDAP integration. I don't have an old Cygwin > installation o that machine anymore, but the results w/ cygserv on the > long latency link match my experience of using that long latency link > "for real" about a year ago. I'm still a bit confused by the results. What "delays" are we looking at if they are not attributable to LDAP? Are they "expected" delays or is that something which is new now? If it's new, is there a simple testcase we can use for further debugging, preferredly one with a single executable showing a certain, debuggable behaviour. This should ideally start with an strace to isolate the problem, and then we can look further. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRLuPzuqvSR.pgp Description: PGP signature
Re: chmod: creator owner victimized? ... (1.7.35-0.4)
Hi Henri, On Feb 25 20:23, Houder wrote: > Hi Corinna, > > Ref: https://cygwin.com/ml/cygwin/2015-02/msg00798.html > - [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4 > > Something for your list of things to think about ... and do later ;-) > > For a directory, the 'creator owner' should have sufficient permissions. That > is, at least 'full control > minus delete'; full control is good. (yes, as far as I can tell) Yeah, I noticed that problem myself a few hours ago and applied a fix in the meantime. In CVS, the chmod workaround does not touch the CREATOR OWNER, CREATOR GROUP and Everyone default ACEs anymore. I'll create a snapshot and another test release soon. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpEH7CegEkyc.pgp Description: PGP signature
Re: slow startup after upgrade
On Feb 25 11:15, John Hein wrote: > Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015: > > Really? This is the first time I see your email address on this ML, and > > there's no name connected to it, so I don't even know if you're usually > > writing under another email address. At least a forename would be nice... > > Bah... sorry, you should get the name in this response. Uh, it's you! :) > > > Running the 20150224 (and *23) snapshot produces the following on Win > > > XP (yes, I know) if cygserver is running: > > > > Sidenote: I'm contemplating to stop supporting XP end of this year. > > I'm thinking it's either related to XP or _something_ with the > particular XP box I'm using (when logged in on the domain, I can't > disable many group policy things or temporarily inhibit AV, so it's > harder to find/eliminate something to pin blame on - certainly may not > be something the latest cygwin is doing when running on XP in a > "large" AD domain). > > I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33 > seconds and enumerates all 8016 entries. 37 seconds with the 2/25 > snap. The timing should be roughly the same, but fluctuations in the low percentage range are normal. > And win 7 doesn't get the 'wrong arg.type' error with the same 2/24 > cygwin1.dll for whatever reason. Interesting. I could reproduce this and it was very certainly a bug in the code, fixed in -25 snapshot and 1.7.35-0.4. > > Works very quickly for me. Problem is, I don't know anything about > > your environment. Are you working remote or in an office? How many > > groups are in your user token? What is the result of this funny > > little statement Dennis created: > > > > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" > & echo !TIME!" > > On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time > stamp > > That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs > running including cygserver. Sounds good to me. > On problematic winxp box: > [passwd, group, db_shell: 'files db', 'files db' & /bin/dash] > 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec > > [passwd, group, db_shell: db, db & /bin/dash] > 23.51, 27.91, 28.78 sec Doesn't sound good at all. Terrible in fact. That a 32 or 64 bit XP? I didn't fire up my XP test machines for ages and I'm not overly enjoying it, but I guess I have to. Oh well, hang on... [...time passes...] [...starting up...] [...XP...] [...32 bit...] [...updating...] [...testing...] Hmm, no. In my case there's no visible delay starting mintty, and tcsh is my login shell, too. mkpasswd and mkgroup are running comparably fast as on my W8.1 64 bit machine I'm using for testing in the first place. Something strange is going on on your XP machine, it seems. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfWnoG8pcQw.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
Corinna Vinschen writes: > I'm still a bit confused by the results. What "delays" are we looking > at if they are not attributable to LDAP? Are they "expected" delays > or is that something which is new now? The echo test can be used as a baseline that is most likely dominated by LDAP responses (not entirely, since there will be a bunch of file lookups in there as well from the bash to the home drive, which in my case is remote). The git tests on the other hand look up, stat and read a bunch of files on top of that and that data needs to take the full roundtrip several times. I've addded those because they are more representative for my usual workload. > If it's new, is there a simple testcase we can use for further > debugging, preferredly one with a single executable showing a certain, > debuggable behaviour. This should ideally start with an strace to > isolate the problem, and then we can look further. I don't think there is a new problem. A few things are interesting (like that one network share that somehow makes the cygserver case slower), but I don't have anything in hand that would permit debugging and it will be hard to isolate it down to Cygwin anyway since there is quite a bit of Windows code involved in all that. In any case, it looks like the behaviour over long latency links is about back to where it was before LDAP integration at least when one uses cygserver for caching. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 25 10:55, Warren Young wrote: > On Feb 25, 2015, at 10:47 AM, Corinna Vinschen > wrote: > > It does... if you stopped and restarted your Cygwin processes afterwards, > > I was sure I had. I don’t run any cygrunsrv processes on that VM, so > I only have to restart MinTTY to make sure Cygwin cleanly reloads. > > Nevertheless, moving nsswitch.conf out of the way, restarting, and > re-running id(1) continues to result in a high UID. > > I don’t know what was going on earlier, but the ghost has evaporated > now. I'm glad I could help exorcising your machine ;) > The FAQ item change is checked in now, by the way. You might want to > give the new text a sanity check. Sound fine to me. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprekff0s7fL.pgp Description: PGP signature
Re: chmod: creator owner victimized? ... (1.7.35-0.4)
> Hi Henri, > > On Feb 25 20:23, Houder wrote: >> Hi Corinna, >> >> Ref: https://cygwin.com/ml/cygwin/2015-02/msg00798.html >> - [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4 >> >> Something for your list of things to think about ... and do later ;-) >> >> For a directory, the 'creator owner' should have sufficient permissions. >> That is, at least 'full control >> minus delete'; full control is good. (yes, as far as I can tell) > > Yeah, I noticed that problem myself a few hours ago and applied a fix in > the meantime. In CVS, the chmod workaround does not touch the CREATOR > OWNER, CREATOR GROUP and Everyone default ACEs anymore. I'll create a > snapshot and another test release soon. Good ... For the record: in addition to RX, W and DC, at least take ownership should be present, I believe. Otherwise, chown will bark. (the example below uses setfacl) Henri - @@ uname -a # using 1.7.35-0.4 CYGWIN_NT-6.1-WOW Seven 1.7.35(0.286/5/3) 2015-02-25 13:11 i686 Cygwin @@ mkdir QL @@ setfacl -b QL < setfacl @@ icacls.sh QL E:/QL Seven\Henri(F) Seven\None (RX) Everyone (RX) CREATOR OWNER (OI)(CI)(IO)(RX,W,DC) < enough? CREATOR GROUP (OI)(CI)(IO)(RX) Everyone (OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ chown Henri:None QL/dir2 # dir2 has been created using Explorer chown: changing ownership of QL/dir2: Permission denied < Euh? @@ icacls.sh QL/dir2 E:/QL/dir2 Seven\Henri(I)(RX,W,DC) CREATOR OWNER (I)(OI)(CI)(IO)(RX,W,DC) Seven\None (I)(RX) CREATOR GROUP (I)(OI)(CI)(IO)(RX) Everyone (I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files @@ ls-facl.sh QL/dir2 E:/QL/dir2 Owner: Seven\Henri < I am the owner! Group: Seven\None DACL(not_protected): Seven\Henriread_execute+write+FILE_DELETE_CHILD allow no_inheritance CREATOR OWNER read_execute+write+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only Seven\None read_executeallow no_inheritance CREATOR GROUP read_executeallow container_inherit+object_inherit+inherit_only Everyone read_executeallow container_inherit+object_inherit SetACL finished successfully. @@ = -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
On Feb 25 21:54, Achim Gratz wrote: > Corinna Vinschen writes: > > I'm still a bit confused by the results. What "delays" are we looking > > at if they are not attributable to LDAP? Are they "expected" delays > > or is that something which is new now? > > The echo test can be used as a baseline that is most likely dominated by > LDAP responses (not entirely, since there will be a bunch of file > lookups in there as well from the bash to the home drive, which in my > case is remote). The git tests on the other hand look up, stat and read > a bunch of files on top of that and that data needs to take the full > roundtrip several times. I've addded those because they are more > representative for my usual workload. > > > If it's new, is there a simple testcase we can use for further > > debugging, preferredly one with a single executable showing a certain, > > debuggable behaviour. This should ideally start with an strace to > > isolate the problem, and then we can look further. > > I don't think there is a new problem. A few things are interesting > (like that one network share that somehow makes the cygserver case > slower), but I don't have anything in hand that would permit debugging > and it will be hard to isolate it down to Cygwin anyway since there is > quite a bit of Windows code involved in all that. > > In any case, it looks like the behaviour over long latency links is > about back to where it was before LDAP integration at least when one > uses cygserver for caching. Ok, that sounds rather comforting for now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYr8HtC9Jvn.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: php-5.6.6-1
The following packages have been updated in the Cygwin distribution: * php-5.6.6-1 * apache2-mod_php5-5.6.6-1 * php-bcmath-5.6.6-1 * php-bz2-5.6.6-1 * php-calendar-5.6.6-1 * php-ctype-5.6.6-1 * php-curl-5.6.6-1 * php-dba-5.6.6-1 * php-devel-5.6.6-1 * php-enchant-5.6.6-1 * php-exif-5.6.6-1 * php-fileinfo-5.6.6-1 * php-ftp-5.6.6-1 * php-gd-5.6.6-1 * php-gettext-5.6.6-1 * php-gmp-5.6.6-1 * php-iconv-5.6.6-1 * php-imap-5.6.6-1 * php-intl-5.6.6-1 * php-ldap-5.6.6-1 * php-mbstring-5.6.6-1 * php-mcrypt-5.6.6-1 * php-mssql-5.6.6-1 * php-mysql-5.6.6-1 * php-mysqli-5.6.6-1 * php-odbc-5.6.6-1 * php-opcache-5.6.6-1 * php-pdo_dblib-5.6.6-1 * php-pdo_mysql-5.6.6-1 * php-pdo_odbc-5.6.6-1 * php-pdo_sqlite-5.6.6-1 * php-pgsql-5.6.6-1 * php-phar-5.6.6-1 * php-posix-5.6.6-1 * php-pspell-5.6.6-1 * php-recode-5.6.6-1 * php-shmop-5.6.6-1 * php-simplexml-5.6.6-1 * php-soap-5.6.6-1 * php-sockets-5.6.6-1 * php-sqlite3-5.6.6-1 * php-sybase_ct-5.6.6-1 * php-sysvmsg-5.6.6-1 * php-sysvsem-5.6.6-1 * php-sysvshm-5.6.6-1 * php-tidy-5.6.6-1 * php-tokenizer-5.6.6-1 * php-wddx-5.6.6-1 * php-xmlreader-5.6.6-1 * php-xmlrpc-5.6.6-1 * php-xmlwriter-5.6.6-1 * php-xsl-5.6.6-1 * php-zip-5.6.6-1 * php-zlib-5.6.6-1 PHP (recursive acronym for 'PHP: Hypertext Preprocessor') is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. This is an update to the latest upstream stable release: http://php.net/ChangeLog-5.php#5.6.6 -- Yaakov -- 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: chmod: creator owner victimized? ... (1.7.35-0.4)
On Feb 25 22:04, Houder wrote: > > Hi Henri, > > > > On Feb 25 20:23, Houder wrote: > >> Hi Corinna, > >> > >> Ref: https://cygwin.com/ml/cygwin/2015-02/msg00798.html > >> - [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4 > >> > >> Something for your list of things to think about ... and do later ;-) > >> > >> For a directory, the 'creator owner' should have sufficient permissions. > >> That is, at least 'full control > >> minus delete'; full control is good. (yes, as far as I can tell) > > > > Yeah, I noticed that problem myself a few hours ago and applied a fix in > > the meantime. In CVS, the chmod workaround does not touch the CREATOR > > OWNER, CREATOR GROUP and Everyone default ACEs anymore. I'll create a > > snapshot and another test release soon. > > Good ... > > For the record: in addition to RX, W and DC, at least take ownership should > be present, I believe. > > Otherwise, chown will bark. (the example below uses setfacl) It won't complain in this case, afaics, but having all standard access rights for the default owner entry was the desired result nevertheless. I fixed that in CVS. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFLrIcUIbcq.pgp Description: PGP signature
Re: slow startup after upgrade
Greetings, Corinna Vinschen! >> > Works very quickly for me. Problem is, I don't know anything about >> > your environment. Are you working remote or in an office? How many >> > groups are in your user token? What is the result of this funny >> > little statement Dennis created: >> > >> > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" >> & echo !TIME!" >> >> On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time >> stamp >> >> That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs >> running including cygserver. > Sounds good to me. >> On problematic winxp box: >> [passwd, group, db_shell: 'files db', 'files db' & /bin/dash] >> 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec >> >> [passwd, group, db_shell: db, db & /bin/dash] >> 23.51, 27.91, 28.78 sec > Doesn't sound good at all. Terrible in fact. That a 32 or 64 bit XP? > I didn't fire up my XP test machines for ages and I'm not overly enjoying > it, but I guess I have to. Oh well, hang on... > [...time passes...] > [...starting up...] > [...XP...] > [...32 bit...] > [...updating...] > [...testing...] > Hmm, no. In my case there's no visible delay starting mintty, and tcsh > is my login shell, too. mkpasswd and mkgroup are running comparably > fast as on my W8.1 64 bit machine I'm using for testing in the first > place. > Something strange is going on on your XP machine, it seems. Although I've migrated to Win7, I'm still using XP systems extensively, many of them have Cygwin, and I didn't see anything even remotely close to his results, ever. His messages basically left me speechless, I was afraid to guess. The half a minute startup of a shell, I could only attribute to environmental issues. -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.02.2015, <00:40> Sorry for my terrible english... -- 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: gid doesn't display correctly on SAMBA share using AD
Greetings, Len Giambrone! >>The other, better way not restricted to Cygwin >> is to install Samba's winbind. > We are running winbind. >>It just doesn't help for existing UNIX >> accounts, afaics. >> > I don't know how winbind works. If it doesn't work with existing UNIX > accounts, then when _would_ it have an effect? The mapping should be set up in winbind to match SID's to UID/GID's. Just "running winbind" isn't enough. -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.02.2015, <00:49> Sorry for my terrible english... -- 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: slow startup after upgrade
Good work -- at least in my environment ;-) 20150225 DLL: mkgroup 0.63s mkpasswd 0.289s compared to 20150220 DLL: mkgroup 45.8s mkpasswd: 4572.7s Output is mkgroup: 53kb, 681 lines mkpasswd: 132kb, 1081 lines. And the output *is* the same :-) Roger. -Original Message- From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Sent: 25 February 2015 12:52 To: cygwin@cygwin.com Subject: Re: slow startup after upgrade On Feb 25 12:29, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > > > While you're at it, does the new snapshot still stop after 3.5K > > > > accounts even though you think there are 8K accounts? > > $ mkpasswd -d | wc > > I get ~30k AD accounts back in 75s instead of 315s and the network traffic > is only half of the former value as well comparing the 20150224 vs. the > latest 20150223 snapshot. Cool! Thanks for your feedback. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer 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
Re: slow startup after upgrade
On 2/25/2015 2:20 PM, Roger Orr wrote: Good work -- at least in my environment ;-) 20150225 DLL: mkgroup 0.63s mkpasswd 0.289s compared to 20150220 DLL: mkgroup 45.8s mkpasswd: 4572.7s Output is mkgroup: 53kb, 681 lines mkpasswd: 132kb, 1081 lines. And the output *is* the same :-) Can somebody summarize where we're at here. I've been noticing all this email about slow startup and I'm excited by the inclusion of domain accounts using /etc/nsswitch.conf, etc. I downloaded a newer version of Cygwin a few weeks ago (I'm seeing 1.7.34) and I experienced the slowdown myself. Unfortunately I'm too busy to actively participate but it looks like some good progress has been made. Should I update or is everything still in snapshots? Thanks in advance. -- Andrew DeFaria http://defaria.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: slow startup after upgrade
On Wed, 2015-02-25 at 15:52 -0800, Andrew DeFaria wrote: > Can somebody summarize where we're at here. I've been noticing all this > email about slow startup and I'm excited by the inclusion of domain > accounts using /etc/nsswitch.conf, etc. I downloaded a newer version of > Cygwin a few weeks ago (I'm seeing 1.7.34) and I experienced the > slowdown myself. Unfortunately I'm too busy to actively participate but > it looks like some good progress has been made. Should I update or is > everything still in snapshots? Fixes are in snapshots, as well as test releases (currently 1.7.35-0.4) which can be installed with setup*.exe. -- Yaakov -- 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: slow startup after upgrade
Andrey Repin wrote at 00:42 +0300 on Feb 26, 2015: > >> On problematic winxp box: > >> [passwd, group, db_shell: 'files db', 'files db' & /bin/dash] > >> 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec > >> > >> [passwd, group, db_shell: db, db & /bin/dash] > >> 23.51, 27.91, 28.78 sec > > > Doesn't sound good at all. Terrible in fact. That a 32 or 64 bit XP? > > I didn't fire up my XP test machines for ages and I'm not overly enjoying > > it, but I guess I have to. Oh well, hang on... > > > [...time passes...] > > [...starting up...] > > [...XP...] > > [...32 bit...] > > [...updating...] > > [...testing...] > > > Hmm, no. In my case there's no visible delay starting mintty, and tcsh > > is my login shell, too. mkpasswd and mkgroup are running comparably > > fast as on my W8.1 64 bit machine I'm using for testing in the first > > place. > > > Something strange is going on on your XP machine, it seems. > > Although I've migrated to Win7, I'm still using XP systems extensively, many > of them have Cygwin, and I didn't see anything even remotely close to his > results, ever. > His messages basically left me speechless, I was afraid to guess. > The half a minute startup of a shell, I could only attribute to environmental > issues. I would not be surprised if some of the malware... err software that our IT folks load onto windows installations is causing some problem (BLODA-like effects in cygwin parlance). If other XP users in AD domains are not having similar trouble, I'm content to chalk this up to a local issue (that is perhaps tickled by some interaction with cygwin 1.7.34+). For now cygserver is an acceptible workaround and some day this XP box will be retired (wiped and replaced with something other than windows). -- 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
Why does CYGWIN double the backslash in execvp()?
Hello,
Here's code that (if BUG is defined) does not work because it looks
like Cygwin doubles the backslash in args[2] when that gets passed to
CMD. If I add a trailing period (#undef BUG), the preceding backslash
does not get doubled, the command runs as it is supposed to.
Why there's an additional backslash in the first case? Should not
args be passed "as is"?
Running under strace confirms the extraneous addition.
---
#include
#include
#define BUG
int main()
{
const char* args[4];
char** xargs;
args[0] = "/cygdrive/c/windows/system32/cmd.exe";
args[1] = "/c";
#ifdef BUG
args[2] = "DIR C:\\";
#else
args[2] = "DIR C:\\.";
#endif
args[3] = 0;
printf("Command = \"%s %s %s\"\n", args[0], args[1], args[2]);
xargs = (char**) &args;
execvp(args[0], xargs);
return 0;
}
---
Compare:
1834 22106 [main] a 7152 child_info_spawn::worker: pid 7152,
prog_arg /cygdrive/c/windows/system32/cmd.exe, cmd line
C:\windows\system32\cmd.exe /c "DIR C:\\")
1595 19614 [main] a 4356 child_info_spawn::worker: pid 4356,
prog_arg /cygdrive/c/windows/system32/cmd.exe, cmd line
C:\windows\system32\cmd.exe /c "DIR C:\.")
Maybe I'm doing something wrong, any ideas?
Thanks,
AL
--
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
