cygserver service won't start

[Alder]

Hi,

I've just reinstalled Cygwin on W2K SP4 over the Internet using
Setup.exe version 2.427 (cygcheck attached). I ran Setup from a Windows
Administrator account. The system itself is not a domain member; it's
simply a workgroup member on a home-based LAN.

Prior to logging in I set the system-wide environment variable
CYGWIN=server in Windows. When I did log in I did so with the Bash
shell from the default shortcut. One of the first things I did was
create my /etc/group and /etc/passwd files with these commands:

$ mkgroup -l -u > /etc/group
$ mkpasswd -l -g > /etc/passwd

I then ran the 'cygserver-config' script OOTB and selected to install it
as a service. This step seemed successful as the Windows Event Viewer
lists it as 'CYGWIN cygserver' and describes it as 'Cygwin shared memory
manager'. This description, however, is suspiciously like the one I
concocted for cygserver during my previous installation of Cygwin, even
though I deleted all temp folders and the Cygnus Solutions keys from the
registry before reinstalling. Is it the default description, or did
Cygwin not get completely uninstalled? FWIW, I was unable to get the
cygserver (or postgresql) running as a service under that previous
installation, hence the reinstall attempt.

The Windows Event Viewer console Application Log reports that cygserver
starts and is awaiting requests, but a split second later the Service
Control Manager reports in the System Log that cygserver terminates
unexpectedly. The /var/log/cygserver.log file is empty, so I'm clueless
as to what might have caused this problem. I can only guess that file
permissions are not what they should be.

If someone could suggest what I might try to get this working, I'd
appreciate it. Thanks.

Alder

[Corinna Vinschen]

Post by Alder
as a service. This step seemed successful as the Windows Event Viewer
lists it as 'CYGWIN cygserver' and describes it as 'Cygwin shared memory
manager'. This description, however, is suspiciously like the one I

The cygserver-config script does not add this description. So it's from
an old service entry.

Post by Alder
The Windows Event Viewer console Application Log reports that cygserver
starts and is awaiting requests, but a split second later the Service
Control Manager reports in the System Log that cygserver terminates
unexpectedly. The /var/log/cygserver.log file is empty, so I'm clueless
as to what might have caused this problem. I can only guess that file
permissions are not what they should be.

What does `ls -l /usr/sbin/cygserver.exe' look like?

Did you try to run cygserver from the command line?


Corinna

[Alder]

This post might be inappropriate. Click to display it.

[Corinna Vinschen]

Post by Alder

Post by Corinna Vinschen

Post by Alder
as a service. This step seemed successful as the Windows Event Viewer
lists it as 'CYGWIN cygserver' and describes it as 'Cygwin shared memory
manager'. This description, however, is suspiciously like the one I

The cygserver-config script does not add this description. So it's from
an old service entry.

That's what I suspected, but I wonder where the string was pulled from?
Like I said, I cleared the Cygnus Solutions keys from LOCAL_MACHINE
and CURRENT_USER areas in the registry and deleted the temp folders
created by the previous Setup.exe. Could it be the Service Control
Manager itself?

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/sshd

is the service key.


Corinna

[Alder]

Post by Corinna Vinschen
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/sshd
is the service key.

Thanks, Corinna. Any more ideas on why cygserver won't run as a
service. Did the permissions I posted look correct?

Cheers,
Alder

[Alder]

Corinna,

I don't know if this is relevant, but I have to add the "/bin" directory
to the cygrunsrv command line in the /bin/cygserver-config file in order
to avoid Windows failing to find the 'cygwin1.dll". So, the line I have is:

if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" \
-p /usr/sbin/cygserver -f "Shared memory manager" \
-2 /var/log/cygserver.err -e PATH="/bin:$PATH"

Regards,

Alder

[Corinna Vinschen]

Post by Alder
Corinna,
I don't know if this is relevant, but I have to add the "/bin" directory
to the cygrunsrv command line in the /bin/cygserver-config file in order
if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" \
-p /usr/sbin/cygserver -f "Shared memory manager" \
-2 /var/log/cygserver.err -e PATH="/bin:$PATH"

Did you know that cygrunsrv adds /bin to $PATH by itself before trying
to run the inferior process for the very reason to find cygwin1.dll?

Adding it explicitely is really unnecessary. Just to be sure, I tried
it again on my machine and it works fine.


Corinna

[Alder]

Post by Corinna Vinschen

Post by Alder
Corinna,
I don't know if this is relevant, but I have to add the "/bin" directory
to the cygrunsrv command line in the /bin/cygserver-config file in order
if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" \
-p /usr/sbin/cygserver -f "Shared memory manager" \
-2 /var/log/cygserver.err -e PATH="/bin:$PATH"

Did you know that cygrunsrv adds /bin to $PATH by itself before trying
to run the inferior process for the very reason to find cygwin1.dll?
Adding it explicitely is really unnecessary. Just to be sure, I tried
it again on my machine and it works fine.

On a perfect platform, perhaps, but like I said, I really had to add it
because without it there a Windows dialog would pop up when I ran
cygserver telling me that 'Cygwin1.dll' could not be found. That was
also true on my previous installation, and one of the reasons I thought
it best to reinstall.

Regards,

Alder

Post by Corinna Vinschen
Corinna

[Igor Pechtchanski]

Post by Alder

Post by Corinna Vinschen

Post by Alder
Corinna,
I don't know if this is relevant, but I have to add the "/bin" directory
to the cygrunsrv command line in the /bin/cygserver-config file in order
if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" \
-p /usr/sbin/cygserver -f "Shared memory manager" \
-2 /var/log/cygserver.err -e PATH="/bin:$PATH"

Did you know that cygrunsrv adds /bin to $PATH by itself before trying
to run the inferior process for the very reason to find cygwin1.dll?
Adding it explicitely is really unnecessary. Just to be sure, I tried
it again on my machine and it works fine.

On a perfect platform, perhaps, but like I said, I really had to add it
because without it there a Windows dialog would pop up when I ran cygserver
telling me that 'Cygwin1.dll' could not be found. That was also true on my
previous installation, and one of the reasons I thought it best to reinstall.

I'm observing similar behavior, but it looks like our causes may be
different.

If your cygcheck showed that you have check_case:strict in your CYGWIN
variable, I'd've guessed that this is another instance of the bug I
reported on the cygwin-developers list (where the PATH got truncated on
converting it back to Win32 format). The fact that cygrunsrv *appends*
/bin to the PATH, whereas you *prepend* it, seems to argue strongly for
this.

Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?
Igor

[Corinna Vinschen]

Post by Igor Pechtchanski

Post by Alder
On a perfect platform, perhaps, but like I said, I really had to add it
because without it there a Windows dialog would pop up when I ran cygserver
telling me that 'Cygwin1.dll' could not be found. That was also true on my
previous installation, and one of the reasons I thought it best to reinstall.

This is weird. I never observed that and I installed a lot of services
using cygrunsrv on a good number of machines.

Post by Igor Pechtchanski
I'm observing similar behavior, but it looks like our causes may be
different.

Igor, out with your debugging experiences!

Post by Igor Pechtchanski
If your cygcheck showed that you have check_case:strict in your CYGWIN
variable, I'd've guessed that this is another instance of the bug I
reported on the cygwin-developers list (where the PATH got truncated on
converting it back to Win32 format). The fact that cygrunsrv *appends*
/bin to the PATH, whereas you *prepend* it, seems to argue strongly for
this.
Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?

Yes, I would be curios as well.


Corinna

[Igor Pechtchanski]

Post by Corinna Vinschen

Post by Igor Pechtchanski

Post by Alder
On a perfect platform, perhaps, but like I said, I really had to add
it because without it there a Windows dialog would pop up when I ran
cygserver telling me that 'Cygwin1.dll' could not be found. That
was also true on my previous installation, and one of the reasons I
thought it best to reinstall.

This is weird. I never observed that and I installed a lot of services
using cygrunsrv on a good number of machines.

Post by Igor Pechtchanski
I'm observing similar behavior, but it looks like our causes may be
different.

Igor, out with your debugging experiences!

I believe they, along with a description of the fix, are summarized in
<http://cygwin.com/ml/cygwin-developers/2004-09/msg00007.html>, which
seems to have been overlooked, as it never got any reply (the rest of the
thread deteriorated into a discussion of the need for check_case:strict).
I'd like to get some feedback on whether my analysis and the fix plan are
correct, before I go through the machinery of getting the patch approved.

Post by Corinna Vinschen

Post by Igor Pechtchanski
If your cygcheck showed that you have check_case:strict in your CYGWIN
variable, I'd've guessed that this is another instance of the bug I
reported on the cygwin-developers list (where the PATH got truncated on
converting it back to Win32 format). The fact that cygrunsrv *appends*
/bin to the PATH, whereas you *prepend* it, seems to argue strongly for
this.
Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?

Yes, I would be curios as well.

FWIW, I ended up using the following for sshd as a workaround:

cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a "-De" -1 /var/log/sshd.log -2 /var/log/sshd.log -e "CYGWIN=check_case:strict ntsec notitle binmode nosmbntsec notty" -e "PATH=/usr/bin:/bin" -t manual -o
^^^^^^^^^^^^^^^^^^^^^^^
Incidentally, -1 and -2 didn't work for me with optional arguments (if I
simply said "-1 -2", stdout was redirected to a file called "-2"). I'm
sure it's unrelated, but thought I'd mention it.

HTH,
Igor

[Christopher Faylor]

Post by Igor Pechtchanski

Post by Corinna Vinschen

Post by Igor Pechtchanski

Post by Alder
On a perfect platform, perhaps, but like I said, I really had to add
it because without it there a Windows dialog would pop up when I ran
cygserver telling me that 'Cygwin1.dll' could not be found. That
was also true on my previous installation, and one of the reasons I
thought it best to reinstall.

This is weird. I never observed that and I installed a lot of services
using cygrunsrv on a good number of machines.

Post by Igor Pechtchanski
I'm observing similar behavior, but it looks like our causes may be
different.

Igor, out with your debugging experiences!

I believe they, along with a description of the fix, are summarized in
<http://cygwin.com/ml/cygwin-developers/2004-09/msg00007.html>, which
seems to have been overlooked, as it never got any reply (the rest of the
thread deteriorated into a discussion of the need for check_case:strict).
I'd like to get some feedback on whether my analysis and the fix plan are
correct, before I go through the machinery of getting the patch approved.

Given the number of problems we've had with strict case checking, I
think it is time to start thinking about ripping it out.

Neither Corinna nor I are huge fans of the functionality and while I
understand that some people like to use it, the amount of extra jumping
hoops required in the code multiplied by the number of times we hear
people complaining about problems seems to indicate that this is not a
robust feature. Corinna essentially implemented this feature under
duress

It's difficult to see without the actual patch but your change seems to
add more logic to cygwin and adds decision points in parts of the code
which are called a lot.

Any time I hear about who great this option is, it seems as though
people raise the issue of finding multiple files with the same name in a
tar file. If this really represents the majority of usefulness for this
feature then I think something like a tar-lint or adding an option to
tar itself might be a better plan than burdening the cygwin DLL with
this feature.

cgf

[Igor Pechtchanski]

Post by Christopher Faylor

Post by Igor Pechtchanski

Post by Corinna Vinschen

Post by Igor Pechtchanski

Post by Alder
On a perfect platform, perhaps, but like I said, I really had to add
it because without it there a Windows dialog would pop up when I ran
cygserver telling me that 'Cygwin1.dll' could not be found. That
was also true on my previous installation, and one of the reasons I
thought it best to reinstall.

This is weird. I never observed that and I installed a lot of services
using cygrunsrv on a good number of machines.

Post by Igor Pechtchanski
I'm observing similar behavior, but it looks like our causes may be
different.

Igor, out with your debugging experiences!

I believe they, along with a description of the fix, are summarized in
<http://cygwin.com/ml/cygwin-developers/2004-09/msg00007.html>, which
seems to have been overlooked, as it never got any reply (the rest of the
thread deteriorated into a discussion of the need for check_case:strict).
I'd like to get some feedback on whether my analysis and the fix plan are
correct, before I go through the machinery of getting the patch approved.

Given the number of problems we've had with strict case checking, I
think it is time to start thinking about ripping it out.

That's your choice, of course, but I already stated my reasons for why I
find this useful. This particular problem results from strict case
checking being overeager in some cases. See below.

Post by Christopher Faylor
Neither Corinna nor I are huge fans of the functionality and while I
understand that some people like to use it, the amount of extra jumping
hoops required in the code multiplied by the number of times we hear
people complaining about problems seems to indicate that this is not a
robust feature. Corinna essentially implemented this feature under
duress.
It's difficult to see without the actual patch but your change seems to
add more logic to cygwin and adds decision points in parts of the code
which are called a lot.

Yes, my changes added extra logic, but mostly because I wanted to keep the
observable impact to a minimum. Upon reflection, it seems like the
particular bit of code that causes this problem was an attempt at
optimization, so that instead of multiple accesses to the same path
failing, the path would simply not be converted at all. IMO, there's no
need for this optimization at all, and that piece of code should just be
excised altogether. I'll send a description of my proposed changes (which
will *simplify* the logic) to cygwin-developers.

Post by Christopher Faylor
Any time I hear about who great this option is, it seems as though
people raise the issue of finding multiple files with the same name in a
tar file. If this really represents the majority of usefulness for this
feature then I think something like a tar-lint or adding an option to
tar itself might be a better plan than burdening the cygwin DLL with
this feature.
cgf

Or CVS, or rsync, or scp, or a whole bunch of other interactions with
case-sensitive operating systems.
Igor

[Christopher Faylor]

Post by Igor Pechtchanski

Post by Christopher Faylor
Any time I hear about who great this option is, it seems as though
people raise the issue of finding multiple files with the same name in
a tar file. If this really represents the majority of usefulness for
this feature then I think something like a tar-lint or adding an option
to tar itself might be a better plan than burdening the cygwin DLL with

Or CVS, or rsync, or scp, or a whole bunch of other interactions with
case-sensitive operating systems.

I said "majority of usefulness" because it appears that the majority of
the time that people mention this it is in relation to tar. But, I
certainly expected to be instructed on the fact that there are other
programs which could be impacted.

Cygwin lived without this feature for a number of years with only
infrequent complaints. I just don't think the benefit outweighs the
impact.

cgf

[Alder]

Post by Igor Pechtchanski
Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?
Igor

Sure, but I'm a little unsure of what this requires. Is it simply a
matter of creating a Windows batch file with this command in it, then
starting the batch file as a service?

Alder

[Igor Pechtchanski]

Post by Alder

Post by Igor Pechtchanski
Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?
Igor

Sure, but I'm a little unsure of what this requires. Is it simply a
matter of creating a Windows batch file with this command in it, then
starting the batch file as a service?

Yep, exactly (except there's a small typo above - it should be "/c").
In other words, something like

echo 'echo %PATH%' > /tmp/test.bat
chmod a+r /tmp/test.bat
cygrunsrv -I test -d "PATH test" -p `which cmd.exe` -a '/c c:\cygwin\tmp\test.bat' -1 /var/log/test.log -2 /var/log/test.log -t manual
cygrunsrv -S test
cygrunsrv -R test

should do just fine. BTW, "cygrunsrv -S" will result in a "service
has not been started" error, but that's expected. Look in
/var/log/test.log for the output.
Igor

[Alder]

Post by Igor Pechtchanski

Post by Alder

Post by Corinna Vinschen

Post by Alder
Corinna,
I don't know if this is relevant, but I have to add the "/bin" directory
to the cygrunsrv command line in the /bin/cygserver-config file in order
if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" \
-p /usr/sbin/cygserver -f "Shared memory manager" \
-2 /var/log/cygserver.err -e PATH="/bin:$PATH"

Did you know that cygrunsrv adds /bin to $PATH by itself before trying
to run the inferior process for the very reason to find cygwin1.dll?
Adding it explicitely is really unnecessary. Just to be sure, I tried
it again on my machine and it works fine.

On a perfect platform, perhaps, but like I said, I really had to add it
because without it there a Windows dialog would pop up when I ran cygserver
telling me that 'Cygwin1.dll' could not be found. That was also true on my
previous installation, and one of the reasons I thought it best to reinstall.

I'm observing similar behavior, but it looks like our causes may be
different.
If your cygcheck showed that you have check_case:strict in your CYGWIN
variable, I'd've guessed that this is another instance of the bug I
reported on the cygwin-developers list (where the PATH got truncated on
converting it back to Win32 format). The fact that cygrunsrv *appends*
/bin to the PATH, whereas you *prepend* it, seems to argue strongly for
this.
Just for the sake of completeness, though, could you please try adding a
service that basically invokes cmd.exe with '-c "echo %PATH%"' as
arguments, and see what the PATH is in the log after starting the service?
Igor

I've never installed a service of my own, so I hope what follows is what
you had in mind:

***@kiraly ~
$ cygrunsrv -I cmd -f "Cygwin PATH test" \
-p /cygdrive/c/winnt/system32/cmd.exe \
-a '-c "echo %PATH%"' \
-1 /var/log/cmd.log -2 /var/log/cmd.err

***@kiraly ~
$ cygrunsrv -Q cmd
Service cmd exists
Type : Own Process
Current State : Stopped
Controls Accepted :

***@kiraly ~
$ cygrunsrv -S cmd
cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062:
The service has not been started.

***@kiraly ~
$ ls -l /var/log
...
-rw-r--r-- 1 SYSTEM Administ 0 Sep 12 15:56 cmd.err
-rw-r--r-- 1 SYSTEM Administ 105 Sep 12 15:56 cmd.log
...

[--- Start cmd.log ---]
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>
[--- End cmd.log ---]

Regards,

Alder

[Alder]

Post by Alder
-a '-c "echo %PATH%"' \

^^^^
After I checked the syntax of the CMD command and was set to change the
dash-c to a slash-C, I looked carefully at the PATH variable I had
defined in Windows and found that I had prepended a misspelled Cygwin
pathname as follows:

D:\cygwn\bin

I removed this and after I restarted Windows the 'cygserver' service,
which had been set on Automatic, started successfully.

My sincere apologies to Igor, Corinna, and the other posters and readers
for wasting your time.

Regards,

Alder

[Dave Korn]

-----Original Message-----
From: cygwin-owner On Behalf Of Corinna Vinschen
Sent: 10 September 2004 09:08

Post by Alder
That's what I suspected, but I wonder where the string was

pulled from?

Post by Alder
Like I said, I cleared the Cygnus Solutions keys from

LOCAL_MACHINE

Post by Alder
and CURRENT_USER areas in the registry and deleted the temp folders
created by the previous Setup.exe. Could it be the Service Control
Manager itself?

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/sshd
is the service key.

Nitpick: that's the sshd service key. The cygserver one, which is created by
the line

if ! cygrunsrv -I cygserver -d "CYGWIN cygserver" -p /usr/sbin/cygserver

from /usr/bin/cygserver-config would have to be

HKLM/SYSTEM/CCS/Services/cygserver

... this would also be consistent with the 'net start' usage info ....

echo "To start it, call \`net start cygserver' or \`cygrunsrv -S
cygserver'."


cheers,
DaveK