[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UX-Problems



    Date: Tue, 8 Oct 1991 03:55 CDT
    From: bwild@negro.fzi.de (Bernd Wild)

    We use now 3 UX boards in our Sun (1 UX400, 2 UX1200) in a shared  
    environment of X-servers (Suns + NeXT) among some staff people and a  
    couple of students. Therefore it happens quiet often that an UX  
    console has to be transfered to another user. We made the experience  
    that this can be done safely ONLY if you first "Halt Machine", and  
    then "shutdown" the FEP. Otherwise you have to kill as superuser the  
    4 ivory-life processes for this board and restart them from scratch.  
	...
We have a similar environment sans the NeXTs.  We often switch the console and
never shutdown the machines.  We often have more than one console open at a
time to the same board.  All we do is use the genera program to bring the
consoles up.  When the person who owns the main console closes it (c-c
genera), someone else who has a console on that board needs to invoke another
genera process to get the main console and the cold-load window, but they
don't have to reboot the UX.  If they want to continue using the console that
they had previously opened, they just iconify the "main" console.
The main grief we have is that people don't like inheriting other peoples
sheets when they start genera (in which case they can use -force to reboot).

    Another common problem is the warning "F_SETLCK: No more record locks  
    available" if you start your genera process. It happens during  
    locking the /etc/ivory<n>.pid file which contains the actual genera  
    console process number for locking against simultaneous access. As we  
    got no staifying answer for this problem from our service we simply  
    killed the file and the genera process started (after printing a  
    warning about the absence of locking).
    Any ideas?

Never seen it.  We did write our own system routine to allow anyone to remove
a lock from the boards.  We only need to remove such locks if machines (Suns
and lispms) crash or get rebooted without freeing locks.

    Bernd Wild