* Cygwin starts take long since march. Three minutes to prompt. @ 2023-04-03 14:38 Thomas Schweikle 2023-04-03 14:47 ` Eliot Moss 0 siblings, 1 reply; 6+ messages in thread From: Thomas Schweikle @ 2023-04-03 14:38 UTC (permalink / raw) To: cygwin [-- Attachment #1.1.1: Type: text/plain, Size: 127 bytes --] Hi! Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? -- Thomas [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 2521 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 321 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin starts take long since march. Three minutes to prompt. 2023-04-03 14:38 Cygwin starts take long since march. Three minutes to prompt Thomas Schweikle @ 2023-04-03 14:47 ` Eliot Moss 2023-04-03 14:59 ` Thomas Schweikle 0 siblings, 1 reply; 6+ messages in thread From: Eliot Moss @ 2023-04-03 14:47 UTC (permalink / raw) To: Thomas Schweikle, cygwin On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: > Hi! > > Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Regards - Eliot Moss ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin starts take long since march. Three minutes to prompt. 2023-04-03 14:47 ` Eliot Moss @ 2023-04-03 14:59 ` Thomas Schweikle 2023-04-03 15:48 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Thomas Schweikle @ 2023-04-03 14:59 UTC (permalink / raw) To: moss, cygwin [-- Attachment #1.1.1: Type: text/plain, Size: 1813 bytes --] Hi! Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: > On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: >> Hi! >> >> Cygwin shell takes about three minutes until the prompt is shown. Any >> idea how to find out the cause? > > I think the most common thing in the past had to do with > probing remote mounts. You could try pruning paths and > see what happens, or adjusting mount parameters. Mounts are: $ cat /proc/mounts C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 I've read somewhere noacl should be given for these mounts. Could not find it, even with a fresh installed cygwin on a fresh windows. Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" errors, even if running as "Administrator" from an elevated shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them back in place for the whole tree? -- Thomas [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 2521 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 321 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin starts take long since march. Three minutes to prompt. 2023-04-03 14:59 ` Thomas Schweikle @ 2023-04-03 15:48 ` Brian Inglis 2023-04-03 16:10 ` Thomas Schweikle 0 siblings, 1 reply; 6+ messages in thread From: Brian Inglis @ 2023-04-03 15:48 UTC (permalink / raw) To: cygwin On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: > Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: >> On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: >>> Cygwin shell takes about three minutes until the prompt is shown. Any idea >>> how to find out the cause? >> I think the most common thing in the past had to do with >> probing remote mounts. You could try pruning paths and >> see what happens, or adjusting mount parameters. > Mounts are: > $ cat /proc/mounts > C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 > C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 > C:/cygwin / ntfs binary,auto 1 1 > C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 > G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 > L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 > M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 > O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 > P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 > T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 > V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 > W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 > X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 > Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 > Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 > I've read somewhere noacl should be given for these mounts. Could not find it, > even with a fresh installed cygwin on a fresh windows. > Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" > errors, even if running as "Administrator" from an elevated shell. Tried both > "cmd.exe" and "powershell.exe". Both did not allow to change acls. > Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them > back in place for the whole tree? Should not need anything special: $ ls -dl / && getfacl / && icacls `cygpath -m /` # sanitized: drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / # file: / # owner: $USER # group: None user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/.../cygwin64 $HOSTNAME/$USER:(F) $HOSTNAME/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 Those kinds of delays are often AD lookup for domain users and groups: see /etc/nsswitch.conf for settings, and consider running cygserver at system or Cygwin startup to preload and cache the info. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin starts take long since march. Three minutes to prompt. 2023-04-03 15:48 ` Brian Inglis @ 2023-04-03 16:10 ` Thomas Schweikle 2023-04-03 18:34 ` Brian Inglis 0 siblings, 1 reply; 6+ messages in thread From: Thomas Schweikle @ 2023-04-03 16:10 UTC (permalink / raw) To: cygwin [-- Attachment #1.1.1: Type: text/plain, Size: 4025 bytes --] Am Mo., 03.Apr..2023 um 17:48:03 schrieb Brian Inglis via Cygwin: > On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: >> Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: >>> On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: >>>> Cygwin shell takes about three minutes until the prompt is shown. >>>> Any idea how to find out the cause? > >>> I think the most common thing in the past had to do with >>> probing remote mounts. You could try pruning paths and >>> see what happens, or adjusting mount parameters. > >> Mounts are: >> $ cat /proc/mounts >> C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 >> C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 >> C:/cygwin / ntfs binary,auto 1 1 >> C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 >> G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 >> L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 >> M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 >> O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 >> P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 >> T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 >> V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 >> W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 >> X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 >> Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 >> Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 > >> I've read somewhere noacl should be given for these mounts. Could not >> find it, even with a fresh installed cygwin on a fresh windows. > >> Trying to reset acls to defaults for "C:\cygwin" gives lots of "access >> denied" errors, even if running as "Administrator" from an elevated >> shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow >> to change acls. > >> Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to >> get them back in place for the whole tree? > > Should not need anything special: > > $ ls -dl / && getfacl / && icacls `cygpath -m /` # sanitized: > drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / > > # file: / > # owner: $USER > # group: None > user::rwx > group::r-x > other::r-x > default:user::rwx > default:group::r-x > default:other::r-x > > C:/.../cygwin64 $HOSTNAME/$USER:(F) > $HOSTNAME/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 $ ls -dl / && getfacl / && icacls `cygpath -m /` drwxr-xr-x 1 SYSTEM SYSTEM 0 Mar 23 13:44 / # file: / # owner: SYSTEM # group: SYSTEM user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/cygwin NT-AUTORITÄT\SYSTEM:(F) NT-AUTORITÄT\SYSTEM:(RX) Jeder:(RX) ERSTELLER-BESITZER:(OI)(CI)(IO)(F) ERSTELLERGRUPPE:(OI)(CI)(IO)(RX) Jeder:(OI)(CI)(IO)(RX) 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten. Is this ok? Not missing "Administrator"? > Those kinds of delays are often AD lookup for domain users and groups: > see /etc/nsswitch.conf for settings, and consider running cygserver at > system or Cygwin startup to preload and cache the info. $ cat /etc/nsswitch.conf # /etc/nsswitch.conf # # This file is read once by the first process in a # Cygwin process tree. # To pick up changes, restart all Cygwin processes. # For a description see https://cygwin.com/cygwin-ug- # net/ntsec.html#ntsec-mapping-nsswitch # # Defaults: # passwd: files db # group: files db # db_enum: cache builtin # db_home: /home/%U # db_shell: /bin/bash # db_gecos: <empty> It is at defaults. -- Thomas [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 2521 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 321 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin starts take long since march. Three minutes to prompt. 2023-04-03 16:10 ` Thomas Schweikle @ 2023-04-03 18:34 ` Brian Inglis 0 siblings, 0 replies; 6+ messages in thread From: Brian Inglis @ 2023-04-03 18:34 UTC (permalink / raw) To: cygwin; +Cc: Thomas Schweikle On 2023-04-03 10:10, Thomas Schweikle via Cygwin wrote: > > > Am Mo., 03.Apr..2023 um 17:48:03 schrieb Brian Inglis via Cygwin: >> On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: >>> Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: >>>> On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: >>>>> Cygwin shell takes about three minutes until the prompt is shown. Any idea >>>>> how to find out the cause? >> >>>> I think the most common thing in the past had to do with >>>> probing remote mounts. You could try pruning paths and >>>> see what happens, or adjusting mount parameters. >> >>> Mounts are: >>> $ cat /proc/mounts >>> C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 >>> C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 >>> C:/cygwin / ntfs binary,auto 1 1 >>> C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 >>> G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 >>> L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 >>> M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 >>> O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 >>> P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 >>> T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 >>> V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 >>> W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 >>> X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 >>> Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 >>> Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 >> >>> I've read somewhere noacl should be given for these mounts. Could not find >>> it, even with a fresh installed cygwin on a fresh windows. >> >>> Trying to reset acls to defaults for "C:\cygwin" gives lots of "access >>> denied" errors, even if running as "Administrator" from an elevated shell. >>> Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. >> >>> Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them >>> back in place for the whole tree? >> >> Should not need anything special: >> >> $ ls -dl / && getfacl / && icacls `cygpath -m /` # sanitized: >> drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / >> >> # file: / >> # owner: $USER >> # group: None >> user::rwx >> group::r-x >> other::r-x >> default:user::rwx >> default:group::r-x >> default:other::r-x >> >> C:/.../cygwin64 $HOSTNAME/$USER:(F) >> $HOSTNAME/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 > > $ ls -dl / && getfacl / && icacls `cygpath -m /` > drwxr-xr-x 1 SYSTEM SYSTEM 0 Mar 23 13:44 / > # file: / > # owner: SYSTEM > # group: SYSTEM > user::rwx > group::r-x > other::r-x > default:user::rwx > default:group::r-x > default:other::r-x > > C:/cygwin NT-AUTORITÄT\SYSTEM:(F) > NT-AUTORITÄT\SYSTEM:(RX) > Jeder:(RX) > ERSTELLER-BESITZER:(OI)(CI)(IO)(F) > ERSTELLERGRUPPE:(OI)(CI)(IO)(RX) > Jeder:(OI)(CI)(IO)(RX) > > 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler > aufgetreten. > > Is this ok? Not missing "Administrator"? Should not matter - depends on your setup. >> Those kinds of delays are often AD lookup for domain users and groups: >> see /etc/nsswitch.conf for settings, and consider running cygserver at system >> or Cygwin startup to preload and cache the info. > > $ cat /etc/nsswitch.conf > # /etc/nsswitch.conf > # > # This file is read once by the first process in a > # Cygwin process tree. > # To pick up changes, restart all Cygwin processes. > # For a description see https://cygwin.com/cygwin-ug- > # net/ntsec.html#ntsec-mapping-nsswitch > # > # Defaults: > # passwd: files db > # group: files db > # db_enum: cache builtin > # db_home: /home/%U > # db_shell: /bin/bash > # db_gecos: <empty> > > It is at defaults. Perhaps read and change to suit your setup, and run cygserver: advantageous if you run a lot of Cygwin processes, or run many processes from cmd/Windows, not under a Cygwin mintty/shell process tree, where the top parent takes the hit. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-03 18:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-03 14:38 Cygwin starts take long since march. Three minutes to prompt Thomas Schweikle 2023-04-03 14:47 ` Eliot Moss 2023-04-03 14:59 ` Thomas Schweikle 2023-04-03 15:48 ` Brian Inglis 2023-04-03 16:10 ` Thomas Schweikle 2023-04-03 18:34 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).