public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin@cygwin.com
Cc: Yuta SUZUKI <suzuyu1729@gmail.com>
Subject: Re: Mintty terminal crashes after changing the default home via nsswitch.conf and launch in a new profile in Windows 11
Date: Wed, 5 Apr 2023 13:55:02 -0600	[thread overview]
Message-ID: <2074517c-9459-ecd7-b679-7f21045a7017@Shaw.ca> (raw)
In-Reply-To: <CAJ_58ir7cFbHcUeUoU3yaGT+zR7yUU9ehcerA4-voG3FtAFe=Q@mail.gmail.com>

On 2023-04-04 20:56, Yuta SUZUKI via Cygwin wrote:
> Thank you for your reply.
> But I can't get the point so much...

>> This setting example is only a suggestion, not meant to be used verbatim, and

> --- Yes. In my lab, I use another path for the default home. This is
> just a simple test configuration.

>> means that, for each Windows account at setup or login, under the user's Windows
>> home directory, you will create a literal "cygwin" subdirectory, to be mounted

> ---- I think that usually cygwin automatically makes the directory
> assigned as the default home in nsswitch.conf (and indeed it does).
> I tried the same experiment with making C:\Users\test\cygwin manually
> before launching cygwin, but the same crash is reproduced.

>> When you change this field from the default, it is up to you to understand and support the setting.

> ---- Well, I know that I want to assign the home directory
> automatically to every user of my lab.
> I don't know the internal structure of cygwin and so what I can do is
> to only announce
> "Do not use cygwin at your very first sign-in to the machine.
> Re-sign-in before launching cygwin".
> But I think this is a bit ridiculous...

Perhaps wait until account initialization is complete before starting Cygwin

>> Cygwin startup is probably waiting for an automounter to provide the directory here,

> ---- Actually, in my experiment, cygwin does make the directory
> C:\Users\test\cygwin
> and even I could output cygcheck to C:\Users\test\cygwin\foo.out (or
> /cygdrive/c/test/foo.out).
> The problem is only in the crash of the window system.
> Addendum:
> Setting Windows environment variable HOME to be /cygdrive/c/users/test
> works without the issue,
> but it does affect another application in my lab as documented in
> cygwin's users guide.
Are you sure that Windows setup, update, AV update, Edge update, and all the 
other junk Windows runs has completed, and the account has been logged in, and 
that account setup has completed, before you start installing Cygwin, and before 
you start running Cygwin?

Also be aware that if you are on a domain, to top process in each Cygwin process 
tree has to access the ADC to load up all the AD related info including all the 
group memberships and rights for the user.
This can takes seconds to minutes, if the ADC is not on a close, fast LAN link.
So wait until you see a Cygwin shell prompt before trying anything.

Perhaps try with a more lightweight app like cmd, rather than File Explorer, 
which easily locks up systems.
Normally switching to TaskMgr, seeing the issue with, and killing the File 
Explorer process tree, resets the system, and restarts File Explorer.

During testing, switch to TaskMgr and check resource usage and waits to see what 
is actually causing the issue.
It is often an app in Cygwin's BLODA Big List Of Dodgy Apps:

	https://cygwin.com/faq/faq.html#faq.using.bloda

a "dodgy" app, often an AntiVirus, Malware, or other monitor, that is not 
written well enough to do its job without interfering with other apps.

This especially applies to Cygwin as it has to work around Windows limitations 
at a low level to implement POSIX compatible syscalls, and AV and monitoring 
applications are not always well written.

Do you have any such software operating on these systems, what is it, is it in 
our BLODA list; what is the system resource usage and what is in wait states 
when the issue occurs?

-- 
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

  reply	other threads:[~2023-04-05 19:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 15:13 Yuta SUZUKI
2023-04-04 19:46 ` Brian Inglis
2023-04-05  2:56   ` Yuta SUZUKI
2023-04-05 19:55     ` Brian Inglis [this message]
2023-04-05 20:29       ` Yuta SUZUKI
2023-04-05 18:44 ` Thomas Wolff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2074517c-9459-ecd7-b679-7f21045a7017@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=cygwin@cygwin.com \
    --cc=suzuyu1729@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).