home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / admin / 6087 < prev    next >
Encoding:
Text File  |  1992-11-07  |  3.5 KB  |  90 lines

  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!portal!mandrews
  3. From: mandrews@portal.hq.videocart.com (Mike Andrews)
  4. Subject: Re: shutdown (was Re: (rsh somehost reboot) never exits)
  5. Message-ID: <BxB1D1.n0y@portal.hq.videocart.com>
  6. Organization: VideOcart Inc.
  7. References: <1992Oct30.172655.2069@thom5.ecsthom5.ecs> <janet.720669557@dunnart> <PD.92Nov3155621@herts.x.co.uk>
  8. Date: Fri, 6 Nov 1992 17:17:25 GMT
  9. Lines: 79
  10.  
  11. In article <PD.92Nov3155621@herts.x.co.uk> pd@x.co.uk (Paul Davey) writes:
  12. >>>>>> On 2 Nov 92 01:59:17 GMT, janet@cs.uwa.oz.au (Janet Jackson) said:
  13. >
  14. >>One of the reasons why shutdown will take so long unnecessarily is that the
  15. >>file /etc/rmtab (which lists all remote machines which have a filesystem
  16. >>currently mounted from the host) will not have entries removed...
  17. >
  18. >Janet> This is the way shutdown should work, but I don't believe it does, at
  19. >Janet> least not under SunOS.
  20. >
  21. >It doesn't, and couldn't unless root on the server was allowed to run
  22. >/etc/unmount (as root) on the client.
  23. >
  24.  
  25. Showmount also shows our PCs that have NFS mounts via Beame & Whiteside NFS.
  26. PCs aren't going to unmount.
  27.  
  28. >Janet> For example, one of our machines, a student server, has never
  29. >Janet> had any of its filesystems mounted on my workstation -- yet
  30. >Janet> when shutdown is run on that server, my workstation gets the
  31. >Janet> messages.
  32. >
  33. >All SunOS machines on the local net receive the message - I think it
  34. >uses rwall, but that name is not present in the binary.
  35. >
  36. >It does not broadcast to other machines (non SunOS) on the net.
  37. >
  38.  
  39. When we shutdown our Auspex, the PCs running B&W NFS, logged in or not, get
  40. the shutdown message as well as all of our Xterminal users who are served by
  41. other Suns.  I suspect that shutdown does a rwall to every network, maybe
  42. with a write to the broadcast address on each attached ethernet. The X users
  43. get the message since they have tty on the Sun machines that NFS mount from the
  44. Auspex over a server backbone.
  45.  
  46. >Janet> I'd probably use shutdown -k), but it won't make much difference to the
  47. >Janet> warning messages.
  48. >
  49. >It doesn't.
  50. > (SunSoft if you are listening a -q (quiet) switch would be nice.)
  51. >
  52. >My procedure for shutting down server machines in a cross mounted network:
  53. >
  54. >1) Run showmount on the server
  55. >
  56. >2) Unmount the remote mounted directories (showmount may lie)
  57. >
  58. >3) Use wall to warn users on local machine (optional!)
  59. >
  60. >4) Check for users with ps (not who or w, which do not report users
  61. >   without a tty - possible with X)
  62. >
  63. >5) Use /etc/halt to halt
  64. >   or  /etc/reboot to reboot
  65. >   or kill -TERM 1 for single user mode
  66. >
  67. >--
  68. >    Paul Davey        Vision Park    UUCP:     pd@ixi.uucp
  69.  
  70.  
  71. Auspex has the shutdown that takes forever on its list of known bugs in 
  72. Auspex's OS release 1.4.1 and recommends the kill -TERM 1:
  73.  
  74. "Very slow system shutdown (0743)
  75.  
  76. "Sometimes shutdowns can be very slow. This may happen if the server tries to
  77. send shutdown messages to clients tahta are not up or that do not have rwall
  78. daemons.
  79.  
  80. "Workaround: Instead of using shutdown to stop the system, try using
  81. kill -TERM 1 to take it to single user mode, and use halt or reboot to bring it
  82. the rest of the way down."
  83.  
  84.                 - Auspex Version 1.4.1 Software release notes
  85.  
  86. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  87. Mike Andrews                                                  VideOcart, Inc.
  88. mandrews@hq.videocart.com                                     300 S. Wacker Dr.
  89. Network Administrator                                         Chicago, IL, USA
  90.