RE: init and xinetd woes

["Jonathan Simms" <jonathan at embassynetworks dot com>]

Thank you so much!

that really did the trick.

-Jonathan

----- Original Message -----
From: "Bill C. Riemers" <cygwin@docbill.net>
To: "Jonathan Simms" <jonathan@embassynetworks.com>; <cygwin@cygwin.com>
Sent: Thursday, August 21, 2003 11:26 AM
Subject: Re: init and xinetd woes


> Hi Jonathan,
>
> I found I had to write a custom /usr/sbin/init.sh script to get init to
work
> properly.  It seems like the sysvinit has nothing in it that actually
> controls setting the runlevels during startup and shutdown.   So I
installed
> the script as the service instead of the init program:
>
> cygrunsrv -I init -p /usr/sbin/init.sh -c /tmp -d 'CYGWIN init' -t auto -s
> INT -o
>
> I find about once every few days, my services stop working for now
apparent
> reason.  In most cases I can restart them with:
>     /sbin/telinit 0;sleep 60;/sbin/telinit 3
>
> However, occasionally, that does not work.  Then I do:
>        cygrunsrv -E init
>         kill -9 <each of the surviving daemons>
>        cygrunsrv -S init
>
> I suspect the main cause of the failure, is execve() does not work the
same
> under Windows and Unix.  For Unix, the new program invoked by the execve()
> command has the same process id as the original.  For Windows, the process
> ID can be different from the original.  Consequently any script that
> does something like:
>         echo $$ > newProgram.id
>         exec newProgram
> might not have the newProgram's PID in the newProgram.id file.  This
raises
> havoc with scripts that try to automatically stop and restart daemons.
>
>                                                        Bill
>
>
> ----- Original Message -----
> From: "Jonathan Simms" <jonathan@embassynetworks.com>
> To: <cygwin@cygwin.com>
> Sent: Thursday, August 21, 2003 4:51 AM
> Subject: init and xinetd woes
>
>
> > hello all,
> >
> > I've been messing around with xinetd and init and I can't seem to get
them
> > to play nicely together.
> >
> > I've checked the archives and have reinstalled xinetd, sysvinit,
> > initscripts, etc., run the appropriate config files (overwriting
existing
> > /etc/*config files) and I still can't get init to start xinetd.
> >
> > /var/log/init.log is empty
> >
> >
> > net start init produces the following output:
> >
> > INIT: version 2.84 booting
> > INIT: Entering runlevel: 3
> > INIT: no more processes left in this runlevel
> >
> >
> >
> > $ ps -e |grep init
> >      2916    3432    2916        816    ?   18 04:41:05 /sbin/init
> >
> > $ ps -e |grep xinetd
> > <blank>
> >
> >
> > i tried doing "chkconfig --level 12345 xinetd on" but it seemed to have
no
> > effect
> >
> > $ chkconfig --list
> >
> > sshd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
> > xinetd          0:off   1:on    2:on    3:on    4:on    5:on    6:off
> > xinetd based services:
> >         chargen:        on
> >         chargen-udp:    on
> >         daytime:        on
> >         daytime-udp:    on
> >         echo:   on
> >         echo-udp:       on
> >         ftpd:   on
> >         imap:   on
> >         rexec:  on
> >         rlogin: on
> >         rsh:    off
> >         rsync:  off
> >         servers:        on
> >         services:       on
> >         talk:   on
> >         telnet: on
> >         time:   off
> >         time-udp:       off
> >
> > there are no init errors in the Event Viewer > Application logs.
> >
> >
> > if i start xinetd "/etc/rc.d/init.d/xinetd start" it starts up alright,
> but
> > as soon as i try to connect (for example, to imap) I get:
> >
> > setuid failed. Permission denied (errno=13)
> >
> > I understand this is because I'm starting the xinetd process under the
> local
> > user account and it needs to be started under the SYSTEM account in
order
> to
> > setuid.
> >
> >
> > if it makes any difference, my /var/lock/subsys dir is empty
> >
> >
> > I've really done the best I can searching google and the archives for
> > answers as to how to resolve this problem. I've spent about 3 hours
trying
> > to get it to work to no avail. I know this list's attitude towards the
> > asking of RTFM questions, or repeating questions easily answered by
> > searching the archives, but I'm really stuck with this one. Please help.
> >
> > -Jonathan Simms
> >
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Problem reports:       http://cygwin.com/problems.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
>


----------------------------------------------------------------------------
----


> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/