public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Erik Soderquist <ErikSoderquist@gmail.com> To: cygwin-xfree@cygwin.com Subject: Re: startxwin.exe no longer exists? Date: Tue, 16 Dec 2014 23:39:00 -0000 [thread overview] Message-ID: <CACoZoo1uEoC=28qEm2j2YBEv1g-DCJy-97muhg6dFLR6VJKFJw@mail.gmail.com> (raw) In-Reply-To: <slrnm91e8d.15ku.varro@anukis.local> <snip> > Apparently not. If I start an X session (using the standard menu item > under the start menu) and manually shut it down, the lock file is not > deleted. On a clean shutdown, the process should clean up its lock files; if it isn't, that needs to looked at and/or reported. The only caveat to that I'm aware of is if a debug flag is set, files the process uses may be intentionally left behind. However, it doesn't sound like you would be setting such flags. <snip> >> I actually have no experience with startxwin; I always called the X >> server directly with the options I wanted. > > What do you mean "directly"? From a mintty or such? Windows .bat/.cmd files, custom crafted shortcut on the desktop, windows registry changes... depends on the situation. The one I referenced with the dumb terminals and flaky power is a registry call in autorun starting a .cmd file. >> However, I can say that freeing of lock files is the job >> of the process that created the lock files. If you kill >> the process, stray lock files are a normal expectation. > > No they're not, unless you restrict "kill" to mean "kill -9" or > equivalent. If you kill a process using just "kill", or by shutting > it down normally, it should clean up its lock file. My apologies; I was only considering kill -9 as 'kill the process'. You are correct, kill -15 is also a kill, but should allow the process to exit cleanly. <snip> >> ... bringing the X system more in line with general X and > *nix standards, which, as far as I know, has always >> been a general goal of the entire Cygwin set of projects. > > Then it's not succeeding. Shutting down X normally under *nix does not > result in left-over lock files. I will certainly agree that shutting down X cleanly should not leave stray lock files behind. I can also say that I'm not experiencing that issue. My best guess (and this is only a guess) is that something is causing X to crash as it shuts down on your system, causing the lock files to be left behind. -- Erik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
next prev parent reply other threads:[~2014-12-16 23:39 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-13 16:20 Will Parsons 2014-12-13 18:17 ` Marco Atzeri 2014-12-16 2:50 ` Will Parsons 2014-12-16 2:56 ` Larry Hall (Cygwin-X) 2014-12-16 3:30 ` Will Parsons 2014-12-16 3:35 ` Larry Hall (Cygwin-X) 2014-12-16 14:29 ` Mark Hansen 2014-12-16 16:00 ` Erik Soderquist 2014-12-16 16:36 ` rcunningham 2014-12-16 17:06 ` Erik Soderquist 2014-12-16 17:23 ` rcunningham 2014-12-16 22:58 ` Will Parsons 2014-12-16 23:39 ` Erik Soderquist [this message] 2014-12-17 17:29 ` mathog 2014-12-17 17:40 ` Erik Soderquist 2014-12-17 17:52 ` mathog 2014-12-17 18:36 ` Erik Soderquist 2014-12-17 19:02 ` mathog
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='CACoZoo1uEoC=28qEm2j2YBEv1g-DCJy-97muhg6dFLR6VJKFJw@mail.gmail.com' \ --to=eriksoderquist@gmail.com \ --cc=cygwin-xfree@cygwin.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: linkBe 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).