On Mon, 2005-03-07 at 14:08 -0800, Bill Campbell wrote: > On Mon, Mar 07, 2005, Michael van Elst wrote: > >On Mon, Mar 07, 2005 at 12:18:03PM -0800, David M. Fetter wrote: > > > >David, > > > >> Restarting AMD while it is in use is a serious problem. > > > >restarting AMD is usually not a problem. You should use > >the restart_mounts option or you have to clean up the > >mounts yourself. You should not use the unmount_on_exit > >option because unmounting might not work if a filesystem > >is busy. > > > >> Since amd has > >> low level hooks into kernel space, if users or processes happen to be > >> using an area that is automounted via AMD and it restarts on them, it > >> basically can cause the entire server to come to a crashing halt. > > > >Areas that are automounted are conventional mounts that are not > >affected by AMD. AMD just provides links and, unlike autofs, > >doesn't hook into kernel space. > > > >More of a problem are NFS servers that do not respond. This may > >freeze amd when it tries to unmount such a server and often causes > >large delays when it tries to restart an existing mount to > >such a server. If you automount /home or use an automounted > >directory accessed in the shell profile you may not be able > >to log into the server anymore. > > > > I've seen problems with Linux servers with multiple IP aliases on the > interface where some Mac OS X systems couldn't connect. Doing some > sniffing, I found that the Linux server, for some odd reason, was replying > with UDP packets from one of the alias addresses, not the primary (eth0) > address. My fix was to force the Apple to use tcp, which is probably more > efficient in any case.
Ah, yes. Most of our servers use virtual ip addresses. Not sure if this could cause extra grief or not. Also, I still might have to maintain that none of the rpms should ever do a restart on their own. This should be a controlled thing that is done through some administrative function. In our environment, one of the biggest problems with OpenPKG right now is that they all want to restart on on upgrade. We cannot have this happen without explicit control and timing over it. It seems to me that this would cause for concern in any production environment. I mean upgrading the software is one thing but willy-nilly restarting it seems a little more unpredictable. I want to be able to upgrade a piece of software, verify it's installation, then do a restart. Not upgrade the software and have it automagically perform the restart while hoping that things do not go awry. Does that make some sense? > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > UUCP: camco!bill PO Box 820; 6641 E. Mercer Way > FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > URL: http://www.celestial.com/ > > ``Are we at last brought to such a humiliating and debasing degradation, > that we cannot be trusted with arms for our own defense? Where is the > difference between having our arms in our own possession and under our own > direction, and having them under the management of Congress? If our defense > be the real object of having those arms, in whose hands can they be trusted > with more propriety, or equal safety to us, as in our own hands?'' > -- Patrick Henry June 9, 1788, in the Virginia Convention on the > ratification of the Constitution. > ______________________________________________________________________ > The OpenPKG Project www.openpkg.org > Developer Communication List openpkg-dev@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
