Michael, Thank you for your response. I'm making my comments within your email. Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 12 Mar 2003 21:52:37 -0500, Art Ross wrote: > > > Rick Johnson wrote: > > > > > Art Ross wrote: > > > > I run a Fundamentals of Linux class which is using RH7.3. I was > > > > teaching the installation and configuration of Samba last night and > > > > encountered a problem on some machines when the students restarted their > > > > super daemon 'xinetd'. This only occurs on a couple of machines and > > > > before I begin digging deeper, I was wondering if you could point in the > > > > direction of some troubleshooting resources or what you might suspect is > > > > the problem. > > > > After installing Samba including the samba-swat package, I have each > > > > adminstrator change the disable key in /etc/xinetd.d/swat file to > > > > 'disable = no'. They must then restart the xinetd daemon to make these > > > > changes take effect. Well, it doesn't on a couple of machines. > > > > Any help is appreciated. > > > > Thanks, > > > > Art > > > > > > Oddly - xinetd doesn't appreciate malformed config entries - double-check > > > all xinetd configs - perhaps diff them against a different machine and see > > > what's different. I remember with a recent upgrade of xinetd, the new > > > version no longer appreciated a method of logging I had chosen. Changing > > > some punctuation in the statement solved the problem. Might be something to > > > go on... > > > > > > And of course, are there any log entries in /var/log/messages? > > > > > > > Rick, > > Thanks for the tip. We finally decided to check the messages file and guess > > what we found. xinetd was failing a missing } at the end of a config file the > > students had to modify. We restarted xinetd and sure enough it worked. > > The error in concept here is that the students were told to modify > xinetd config files themselves rather than simply running "chkconfig > swat on" which would enable Samba SWAT and trigger xinetd hard > reconfiguration. I think I remember seeing these instructions in the newer documentation but had the students do it the way I'd turned on services in the past. I'll have to give this a try. On another note, with the situation these students have created, is the best avenue to review the /var/log/messages file for clues of what is wrong or is there something in addition to it. One of the students was able to get their 'xinetd' up after adding a missing } in the /etc/xinetd.d/swat file. We were lead there by the messages file. > > > > Is there any time that xinetd wouldn't work because of conflicting ports > > being requested by to different services? > > No. First come first served. It would disable the second service > that tries to bind on an already used port. And it would log an > appropriate error message. So make sure, you avoid non-unique config > ids and duplicate ports. Help me with the config id's!!! Are these similar to the pid's which are reported and saved in pid files? As for the ports I think the /etc/service file has the swat port assignment set with the 7.3 install. I assumed that no conflicts would exist. Is this a bad assumption? Thanks and Best Regards, Art > > > - -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+cGii0iMVcrivHFQRAo7+AJ4u/U2YIdNDCcj946Cjb1gq2bM2fACgg+hP > /fEw6D1nzNII3yGIcg4uT0I= > =w/IT > -----END PGP SIGNATURE----- > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
