F9: Problem with Services tool

[Craig White]

On Fri, 2008-07-11 at 16:53 -0700, Dan Thurman wrote:
> Craig White wrote:
> >
> > On Fri, 2008-07-11 at 15:15 -0700, Dan Thurman wrote:
> > > Michael Schwendt wrote:
> > > > On Fri, 11 Jul 2008 11:42:15 -0700, Dan Thurman wrote:
> > > >
> > > > > Michael Schwendt wrote:
> > > > > >
> > > > > > On Fri, 11 Jul 2008 07:31:36 -0700, Dan Thurman wrote:
> > > > > >
> > > > > > > Daniel B. Thurman wrote:
> > > > > > > >
> > > > > > > > Somehow, the system-conf-services tool stopped working.
> > > > > > > > Starting this brings up the tool, it hangs with a blank
> > > > list
> > > > > > > > and 'No services selected' in a greyed out right panel.
> > > > > >
> > > > > > > Isn't there anyone that can help me solve this one?  I am
> > > > really
> > > > > > > pulling out my hair over this supposedly *simple* program
> > > > > > > and I cannot for the life of me figure out why this sucker
> > > > hangs!
> > > > > >
> > > > > > Be somewhat creative. No immediate need to debug the Python code
> > > > in
> > > > > > /usr/sbin/system-config-services, but you could move all service
> > > > scripts
> > > > > > from /etc/init.d to a backup location, install a single script
> > > > and see
> > > > > > whether that changes anything. With binary search you could find
> > > > out
> > > > > > whether any of the scripts causes s-c-s to malfunction. Else,
> > > > next would
> > > > > > be to empty /etc/rc.d/rc?.d (and/or examine it for circular
> > > > links or
> > > > > > similar damage) and see whether that helps. If it doesn't, real
> > > > debugging
> > > > > > might be necessary.
> > > > > >
> > > > > All of files moved out into a temp area and add one-by-one into
> > > > the
> > > > > respective
> > > > > places?  If so, do I remain in booted state and do a Kill -1 1 or
> > > > > something to
> > > > > test this out?  What scares me is that if I reboot at each test,
> > > > would I
> > > > > be caught
> > > > > in a state that I could never log in?
> > > > >
> > > > > Please advise how I should go about this?
> > > >
> > > > Don't reboot, don't kill anything, just restart
> > > > system-config-services
> > > > from within a terminal. It's just a quick test whether any service
> > > > will show up or if the problem is entirely elsewhere.
> > > >
> > > OK FOLKS!  HERE IS THE SCOOP!
> > >
> > > I followed up on Mike suggestion and found the following:
> > > =======================================================
> > > * SELinux is preventing gam_server (gamin_t) "dac_override" to
> > > <Unknown> (gamin_t).
> > >
> > > innd             - gamin se-error (*)
> > > mimedefang       - gamin se-error (*)
> > > pure-ftpd        - hard-hang
> > > vncserver        - hard hang
> > > xguest           - hard hang
> > > xinetd           - hard hang
> > > xl2tpd           - hard hang
> > > xpilot-ng-server - hard hang
> > > ypbind           - hard hang
> > > yppasswdd        - hard hang
> > > ypserv           - hard hang
> > > ypxfrd           - hard hang
> > > xttpd            - hard hang
> > > yum-cron         - hard hang
> > > yum-updateonboot - hard hang
> > > yum-updatesd     - hard hang
> > > zabbix           - hard hang
> > > zabbix-agent     - hard hang
> > > zaptel           - hard hang
> > > zebra            - hard hang
> > > zoneminder       - hard hang
> > > zope             - hard hang
> > > zvbid            - hard hang
> > > =======================================================
> > >
> > >
> > > I am not claiming *anything* but just showing you what
> > > you *might* run into.  I have tested each one over and
> > > over and for me, if any of the above is in /etc/init.d
> > > it hangs or it spits out a .py error message.
> > >
> > > If could be a s-c-s problem or the scripts - I am not
> > > an expert so -- take it with a grain of salt.
> > >
> > > ASAIK - all the services *seem* to work fine - it is
> > > just the s-c-s has a problem accessing these scripts.
> > >
> > > You can get by without having to deal with the s-c-s
> > > program by using chkconfig directly so there is the
> > > "old" way of doing things so no problem here.  All
> > > along I thought there was *something else* wrong with
> > > the services itself - no, I don't think so but then
> > > I never say never ;)
> > >
> > > This took a long time for me to "divide and conquer"
> > > but there you have it! :D
> > >
> > > Someone has some work cut out for them!  I am just
> > > a USER.
> > >
> > > Cheers!
> > > Dan
> > ----
> > please - no html to list
> >
> > You know of course that everyone has some of these things and they don't
> > have the same issues so be careful on drawing any massive conclusions.
> >
> I believe that I created most of the problems for myself by installing
> many (if not all) packages willy-nilly indeed, and I suppose this is
> a learning process for me.  Granted, I agree with you - I should not
> have made some of the comments above.  Anyway, it appears that
> there are many files created in /etc/init.d that seems to be "empty
> shells" - I did not find some of these matching against what the
> rpm database contains - so for some of these I have removed them
> and for others, I have actually removed packages that I do not need.
> 
> I have one outstanding issue - and that is the xinetd script.  I had
> installed the package xinetd - but realize after the fact - that it was
> not really needed since it was never installed in the first place.
> 
> So can I safetly yum remove xinetd?  I have a feeling that something
> else is in it's place or xinetd is no longer used in F9?
> 
----
xinetd isn't installed by default but there are programs that may bring
it in as a dependency because it's connections are made via xinetd (i.e.
I think samba-swat and others).

sure, run yum remove xinetd and see what it wants to remove besides
xinetd if anything. You can always say no.

Craig