This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Curious behavior of CYGSERVER

Conrad Scott wrote:

"David A. Cobb" <> wrote:

*And really nice if there were at least a
/usr/doc/cygwin/cygserver.readme* Nothing fancy, just tell what we
should expect and what to be wary of.

As I just mentioned in a different thread and as I kept forgetting to
mention earlier in this thread, cygserver (at the moment) does
(effectively) nothing (the entry points for the IPC calls are
deliberately missing from the DLL export list).  I could (and probably
should) write a README to that effect.  (Watch this space etc.)

Well, for something that "does nothing" it has an amazing effect on my processing!! Without it I hang up 100% of the time [the other thread]. With it I run much more quickly and I do, sometimes, run to completion.

Which brings me to the question: why are you running cygserver at all?

Started just to see what would happen.  Liked the result, stayed with it.

In another message in this thread, you mention that the configure ran
more quickly with cygserver than without.  This is probably due to the
/tmp/cygdaemo socket file I mentioned in another thread.  If you run
cygserver and then kill it, it leaves this file behind, which causes all
cygwin processes to pause for a second (or so).  So, if you've run
cygserver and are no longer running it, find and remove the
/tmp/cygdaemo file.  Don't remove it if you are currently running


Of course, the main advice is just not to run cygserver at all right
now, since it doesn't provide any functionality.

As for your other point about stdout redirection problems when running
cygserver, I find it hard to see how this has anything to do with
cygserver especially since you say the redirection file doesn't even get
created.  The file is created by the shell itself and for this not to
happen indicates that something wierd and wonderful is happening.

Hypothesis: the stdout /is/ written, however for whatever reason it isn't being properly closed. Thus it never gets a good directory entry. I haven't run the disk scan in a while. HOLD ON. . . . . Well, no lost chains or other filesystem faults, anyway. It appears only to happen if the redirected file is pretty large -- this would match Nicholas's experience. If I do a "normal" experiment with a real small stdout ( echo "`date`" ) the file IS created and correct. If I do a configure or make that would be expected to generate a very LARGE file -- nope! no file. And it's obvious that if NO redirection worked, configure and make would suffer a very early demise.

Just the kind of error I especially hate. What's happening is clearly important.

In any case, as I mentioned before, I need to see the
`cygcheck -s -v -r' output from your machine before we can get any
further with this.

I hope, by now, you've seen one of the two I've posted!

David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]