From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200401311644.i0VGiah20241@zamenhof.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] boot via aan from fileserver? In-reply-to: Your message of "Sat, 31 Jan 2004 12:03:14 +0100." <200401311103.i0VB3F518364@zamenhof.cs.utwente.nl> References: <200401311103.i0VB3F518364@zamenhof.cs.utwente.nl> From: Axel Belinfante MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20237.1075567476.1@zamenhof.cs.utwente.nl> Date: Sat, 31 Jan 2004 17:44:36 +0100 Topicbox-Message-UUID: c98065bc-eacc-11e9-9e20-41e7f4b1d025 Just for those interested: > In the mean time, after being away for a day, I find at home that > my connection has been down long enough such that a machine > booted 'normally' from the work fs gives the 'i/o on hungup channel' > whereas the 'tcpaan' booted one does not complain but simply > hangs and waits -- seems what I'm doing does not (yet?) give > me what I'm looking for... After thinking about the code of aan.c I supected that the syslog(0, ...) calls in the if(dialstring) branch of reconnect() were causing the problems: network problem -> pending connection to fs -> trying to consult fs to see if we can write to a log file not possible -> deadlock while waiting for the result of the log file existence test?!? Experiments seem to confirm this -- replacing those calls to syslog(0, Logname, ...) by calls to dmessage(0, ...) seems to have solved the problem. Now my only remaining problem is to make a number of connections to u9fs reliable as well. Since there is no unix aan, easiest trick seems to mount them all on the cpu server (where I mount them anyway) and reexport from there. If there were something like aan for unix, I could maybe even mount those u9fs things on the cpu server via /lib/namespace.$sysname (and then on the terminal at home in the same way) Axel.