![](https://seccdn.libravatar.org/avatar/22360e1aa631a0253952f3bc93db1666.jpg?s=120&d=mm&r=g)
When attempting to log into a server from a kdm login screen to an nfs server, the login stops part way through when loading kde from the server. The error when doing a rcnfs reload is: /home: device is busy The only way to get the client back up to try and relogin is to go to runlevel 6 and reboot. Can anyone help? I think it's toi do with timeo in fstab but I'm not sure. what causes this error? Thanks, Steve.
![](https://seccdn.libravatar.org/avatar/6c37c3c79825c341debabdc6e7a0e2e0.jpg?s=120&d=mm&r=g)
steve-ss
When attempting to log into a server from a kdm login screen to an nfs server, the login stops part way through when loading kde from the server.
Several notes here: (1) The user does not log into the NFS server. He or she logs into the NFS client and accesses files in his or her home directory via NFS. (2) It's not the login process that stops, it's the KDE environment which doesn't start. The login process has already finished at this stage. (3) KDE is not loaded from the server, only the files in /home are accessed via NFS. I hope you see why some people are extremely confused by your description. To be a bit more constructive, here is a translation to language which I understand better: When a user starts a kdm session on a machine which mounts the /home directory from an NFS server, the KDE hangs in the initialization phase.
The error when doing a rcnfs reload is: /home: device is busy
Probably, there are blocked processes on the NFS client which access files on the NFS server. I'm not sure what "mount -a" does in this case, it may not be an error. Anyway, you may want to kill those blocked processes but not to re-mount the NFS filesystem. -- A.M.
![](https://seccdn.libravatar.org/avatar/22360e1aa631a0253952f3bc93db1666.jpg?s=120&d=mm&r=g)
On Saturday 17 January 2004 11:58, Alexandr Malusek wrote:
steve-ss
writes: When attempting to log into a server from a kdm login screen to an nfs server, the login stops part way through when loading kde from the server.
Several notes here: (1) The user does not log into the NFS server. He or she logs into the NFS client and accesses files in his or her home directory via NFS. (2) It's not the login process that stops, it's the KDE environment which doesn't start. The login process has already finished at this stage. (3) KDE is not loaded from the server, only the files in /home are accessed via NFS.
I hope you see why some people are extremely confused by your description. To be a bit more constructive, here is a translation to language which I understand better:
Yes, now I can see why my description is bad.
When a user starts a kdm session on a machine which mounts the /home directory from an NFS server, the KDE hangs in the initialization phase.
Yes, exactly. it's the kde hanging problem I'm trying to sort out.
The error when doing a rcnfs reload is: /home: device is busy
Probably, there are blocked processes on the NFS client which access files on the NFS server. I'm not sure what "mount -a" does in this case, it may not be an error. Anyway, you may want to kill those blocked processes but not to re-mount the NFS filesystem.
Thanks again. One day, we may solve this problem. If anyone has any ideas of why the kde hangs please tell! Steve.
![](https://seccdn.libravatar.org/avatar/d72d740c1430f8de914b88014635309e.jpg?s=120&d=mm&r=g)
steve-ss wrote:
Thanks again. One day, we may solve this problem. If anyone has any ideas of why the kde hangs please tell!
Steve.
Hi Steve, Pitching a little late here but ... How many users log in to their client machines at the same time with the same user ID and are these user home directories actually the same homedirs exported to the clients? I'm trying to see whether many clients are trying to write to one set of .kde files. Damian
![](https://seccdn.libravatar.org/avatar/22360e1aa631a0253952f3bc93db1666.jpg?s=120&d=mm&r=g)
On Saturday 17 January 2004 12:46, Damian O'Hara wrote:
steve-ss wrote:
Thanks again. One day, we may solve this problem. If anyone has any ideas of why the kde hangs please tell!
Steve.
Hi Steve,
Pitching a little late here but ...
How many users log in to their client machines at the same time with the same user ID and are these user home directories actually the same homedirs exported to the clients?
I'm trying to see whether many clients are trying to write to one set of .kde files.
Hi damian, Hi everyone. 20 users all log into the same user id and these are the same user home directories exported yes. i think I can see the problem: all users are trying to update ingle .kde files at the same time. So what it needs is for each user to have his own login no? That is you cannot have more than one user with the same id logging into the same directory. This makes sense as users who have their own account never have this problem. Maybe it wansn't nfs afterall. Is it practical to have 200 different logins on the same server? Will NIS cope with that? It would certainly be a nightmare to organise it in mid term with 200 kids hanging around! Can anyone confirm the .kde behaviour? Thanks, Steve.
![](https://seccdn.libravatar.org/avatar/6c37c3c79825c341debabdc6e7a0e2e0.jpg?s=120&d=mm&r=g)
steve-ss
20 users all log into the same user id and these are the same user home directories exported yes. i think I can see the problem: all users are trying to update ingle .kde files at the same time.
As far as I know, KDE can handle a user which uses his account from different machines simultaneously (it uses file names as .DCOPserver_<hostname>_:0). But there may be a race condition in updating for instance the ~/.Xauthority file. Each kdm session writes an authorization information there and if it fails then X clients cannot access the X server. In other words, KDE cannot start then. I suggest you try a separate account for each machine, e.g. pcA01, pcA02, ...
Is it practical to have 200 different logins on the same server?
You don't need a separate login for each kid, just for each computer. This approach is also used in computer classes on universities. This prevents two users from modifying the same file - you definitely want to avoid this situation. We also have special accounts which are shared by several people but these accounts are used quite rarely.
Will NIS cope with that?
Yes. Anyway, if the disk performance is a problem, then you may try to use a ramdisk or a filesystem mounted by the loop device on the NFS server. -- A.M.
participants (3)
-
Alexandr Malusek
-
Damian O'Hara
-
steve-ss