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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
