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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
