Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!liam From: liam@cs.qmw.ac.uk (William Roberts) Newsgroups: comp.unix.aux Subject: Re: Personal System Folders and NFS Message-ID: <2780@redstar.cs.qmw.ac.uk> Date: 3 Dec 90 16:41:21 GMT References: Sender: usenet@cs.qmw.ac.uk Distribution: comp Lines: 47 Nntp-Posting-Host: whitesand In hosking@cs.umass.edu (Tony Hosking) writes: >I am having trouble with personal system folders (created using the >systemfolder command) for users whose home directories are on an NFS-mounted >volume. When the user logs in at the console things go really slowly, with >some disk activity, then eventually the login just gives up and the Login >dialogue box comes back. No error messages, nothing, just plain refusal to log >in. If I remove the personal System Folder from the user's remote home >directory then they can log in again with no problems. Does anyone have any >idea what's going on and how to fix the situation? I have no problem with >personal system folders for users having a local home directory. Perhaps this >is a bug in A/UX 2.0? Has anyone else encountered this? All our users have home directories on NFS fileservers, and we have for now rejected the whole idea of personal system folders because we couldn't make them work satisfactorily: we did sometimes manage to login, but it wasn't very reliable and horrendously slow. I doubt that this is a bug in A/UX 2.0, just that some things are done in ways which are very inefficient via NFS. The only NFS-related snag we have had is that /mac/bin/Login tries to write the user's .aux_prefs file (which records the session type) as root, which falls foul of the uid 0 -> uid 65534 translation. We tried having personal system folders, but local .fs_cache, .fs_dirIDs, DesktopDB and Desktop DF files, i.e. the personal System Folder had symbolic links to local versions of these files, but this didn't work because the .fs_* files were removed almost instantly and re-written (onto the NFS fileserver). We now think that this might be due to date problems making the .fs_cache look out of date, but we haven't tried repeating the experiments yet. We've also given up on accumulating a Desktop database: we have a compressed cpio archive containing clean, sensible versions of the files mentioned above, and we recreate the files from that archive for EVERY login (as part of the /mac/bin/mac32 script). We also use a semaphore so that an INIT can let the outside world know when startmac has finally started, and we run the CommandShell after that. The current "CommandShell &" scheme relies on everything happening before CommandShell's patience runs out, and that wasn't reliable either if the previous Mac session had died or been terminated brutally. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)