public inbox for
help / color / mirror / Atom feed
From: Erik Soderquist <>
Subject: Re: startxwin.exe no longer exists?
Date: Tue, 16 Dec 2014 23:39:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <slrnm91e8d.15ku.varro@anukis.local>

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

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

>> ... 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:
Problem reports:

  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:

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

  git send-email \
    --in-reply-to='' \ \ \

* 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).