Multiple Concurrent KDE Logins On A Single Home Directory?
Hi, I recently tried a FreeNX login as a potential fallback while I sort out a problem with a KVM switch with a poor implementation of its USB hub. NX seems to work quite well, at least over a 100 megabit LAN and it seems like a good solution (and a lot cheaper than a four-port DVI / USB KVM!). However, as soon as I logged in, it occurred to me that I was already logged in directly to the same account on the target host. I quickly logged out of the NX session and have seen no evidence of any configuration file corruption from that brief login. But now I'm curious whether there is a problem either in principle or in practice with having two (or more) concurrent KDE logins to a single account / home directory. If anyone has experience with or knowlege of this situation, I'd appreciate hearing it. Randall Schulz
On Wednesday 18 October 2006 19:19, Randall R Schulz said:
I recently tried a FreeNX login as a potential fallback while I sort out a problem with a KVM switch with a poor implementation of its USB hub. NX seems to work quite well, at least over a 100 megabit LAN and it seems like a good solution (and a lot cheaper than a four-port DVI / USB KVM!).
However, as soon as I logged in, it occurred to me that I was already logged in directly to the same account on the target host. I quickly logged out of the NX session and have seen no evidence of any configuration file corruption from that brief login. prints But now I'm curious whether there is a problem either in principle or in practice with having two (or more) concurrent KDE logins to a single account / home directory.
If anyone has experience with or knowlege of this situation, I'd appreciate hearing it.
It's not so much Don't Do It, as We Aren't Responsible If You Do. I often log in quickly over NX when there is already a local session running, without problems. It's a very bad idea to run two kmails side by side on the same account, as the local mbox/maildirs are not built for concurrent access and the indices are mmap'ed for speed. KMail checks for any instance already running and shows dire warnings, which you should heed. I'd also be careful about installing more software while using multiple logons, as kbuildsycoca would probably run simultaneously and might create a corrupt syscoca, leading to missing kpart/plugin errors etc. Not 100% sure what it does in that case though. Apps that use sqlite (amarok) might also have multiple access issues. Also configuration file corruption is one thing, but you would definitely notice that if instance 2 quits after instance 1, any config changes made by instance 1 would be lost. HTH Will
Will, On Thursday 19 October 2006 01:31, Will Stephenson wrote:
On Wednesday 18 October 2006 19:19, Randall R Schulz said:
... But now I'm curious whether there is a problem either in principle or in practice with having two (or more) concurrent KDE logins to a single account / home directory.
...
It's not so much Don't Do It, as We Aren't Responsible If You Do. I often log in quickly over NX when there is already a local session running, without problems.
It's a very bad idea to run two kmails side by side on the same account, as the local mbox/maildirs are not built for concurrent access and the indices are mmap'ed for speed. KMail checks for any instance already running and shows dire warnings, which you should heed.
For my scenario, that wouldn't happen, since I run KMail on only one machine.
I'd also be careful about installing more software while using multiple logons, as kbuildsycoca would probably run simultaneously and might create a corrupt syscoca, leading to missing kpart/plugin errors etc. Not 100% sure what it does in that case though. Apps that use sqlite (amarok) might also have multiple access issues.
OK. Software installation is not too common an action, at least not once the system is up and running and configured as I want it. I don't do much media on my Linux systems. I have a Mac for that stuff...
Also configuration file corruption is one thing, but you would definitely notice that if instance 2 quits after instance 1, any config changes made by instance 1 would be lost.
I guess the answer, if I want to make this a regular thing, is to simply avoid the multiple concurrent KDE logins thing.
HTH
Yes, thanks.
Will
Randall Schulz
On Thursday 19 October 2006 14:39, Randall R Schulz wrote:
For my scenario, that wouldn't happen, since I run KMail on only one machine.
You could end up trying to run it twice if login 2 restores the same session currently running/restored in login 1. The safety check catches this case though.
Also configuration file corruption is one thing, but you would definitely notice that if instance 2 quits after instance 1, any config changes made by instance 1 would be lost.
I guess the answer, if I want to make this a regular thing, is to simply avoid the multiple concurrent KDE logins thing.
'Avoid' is a bit strong here. It's more of a case of gotchas than risks. A tip is to set KDEHOME, KDEVARTMP and KDETMP differently depending on DISPLAY, that way you can access your files, have a separate KDE config for the smaller NX display and avoid all the gotchas. Will -- Will Stephenson
Will, On Thursday 19 October 2006 09:41, Will Stephenson wrote:
On Thursday 19 October 2006 14:39, Randall R Schulz wrote:
For my scenario, that wouldn't happen, since I run KMail on only one machine.
You could end up trying to run it twice if login 2 restores the same session currently running/restored in login 1. The safety check catches this case though.
No. I have two machines. On one I run KMail, on the other I do not. I'd only use NX to log on from the KMail machine to the non-KMail machine. Hence, there would be no problem with multiple KMail instances. Furthermore, I'm careful never to log out with a random collection of applications running (to be auto-started upon my next login). I have only a Konsole and a Konqueror local file browsing window. I start other applications, such as KMail and Firefox when I log in and launch other less generic applications on an as-needed basis.
Also configuration file corruption is one thing, but you would definitely notice that if instance 2 quits after instance 1, any config changes made by instance 1 would be lost.
I guess the answer, if I want to make this a regular thing, is to simply avoid the multiple concurrent KDE logins thing.
'Avoid' is a bit strong here. It's more of a case of gotchas than risks.
A tip is to set KDEHOME, KDEVARTMP and KDETMP differently depending on DISPLAY, that way you can access your files, have a separate KDE config for the smaller NX display and avoid all the gotchas.
That sounds like a good idea. I'll keep it in mind. I'm not sure what you mean by "smaller NX display." I'm a fanatic about screen real estate and always do remote logins in full-screen mode.
Will
Thanks for the tips. Randall Schulz
participants (2)
-
Randall R Schulz -
Will Stephenson