Multiple instances of Firefox over X11

firefoxx11

I have a jump server that I use to log into to access the other application server over a VPN. However this jump server is used by many people.

so if one persons open Firefox to be forwarded over x11 another person cannot open Firefox. It gives the bellow error.

The error it gives when I run 'firefox &'

so basically only one instance

linux-fs:~/.vnc # ps aux | grep firefox
root      8979  0.5  0.7 700000 118212 pts/1   Sl   17:56   0:02 firefox -height 800 -width 740
root     11421  0.0  0.0   4408   772 pts/2    S+   18:05   0:00 grep firefox

Is there any way more can be configured ?

Best Answer

Every Firefox user is associated with a profile. This profile basically contains all the preferences, history, bookmarks etc. When Firefox starts, it puts a lock on the profile. This ensures that no other Firefox process uses this profile.

But, this doesn't mean that there can be only one instance of Firefox. It just means there can be only one instance of Firefox per profile. Since the jump server is used by different people, you can ask each of them to create a different profile and use their own profile.

But this is a huge inconvenience. Every time someone starts Firefox, a window appears asking what profile to use.

This is a weak solution because there is no one to enforce if someone is using their profile or not. So, other solution would be that if you find someone using Firefox, open Firefox profile manager with

firefox -no-remote -ProfileManager

and create a new profile. Then start Firefox using this profile. You can delete this profile when you are done with it.

Related Solutions

SSH Performance – Why is Firefox So Slow Over SSH?

The default ssh settings make for a pretty slow connection. Try the following instead:

ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote

The options used are:

-Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
         subjected to the X11 SECURITY extension controls.
 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11 and TCP connections).  The
         compression algorithm is the same used by gzip(1), and the
         “level” can be controlled by the CompressionLevel option for pro‐
         tocol version 1.  Compression is desirable on modem lines and
         other slow connections, but will only slow down things on fast
         networks.  The default value can be set on a host-by-host basis
         in the configuration files; see the Compression option.
 -4      Forces ssh to use IPv4 addresses only.
 -c cipher_spec
         Selects the cipher specification for encrypting the session.

         For protocol version 2, cipher_spec is a comma-separated list of
         ciphers listed in order of preference.  See the Ciphers keyword
         in ssh_config(5) for more information.

The main point here is to use a different encryption cypher, in this case arcfour which is faster than the default, and to compress the data being transferred.

NOTE: I am very, very far from an expert on this. The command above is what I use after finding it on a blog post somewhere and I have noticed a huge improvement in speed. I am sure the various commenters below know what they're talking about and that these encryption cyphers might not be the best ones. It is very likely that the only bit of this answer that is truly relevant is using the -C switch to compress the data being transferred.

Linux Swap – System Becomes Unresponsive Despite Free RAM

shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo, available on kernels 2.6.32, displayed as zero if not available)>

So the manpage definition of Shared is not as helpful as it could be :(. If the tmpfs use does not reflect this high value of Shared, then the value must represent some process(es) "who did mmap() with MAP_SHARED|MAP_ANONYMOUS" (or System V shared memory).

6G of shared memory on an 8G system is still a lot. Seriously, you don't want that, at least not on a desktop.

It's weird that it seems to contribute to "buff/cache" as well. But I did a quick test with python and that's just how it works.

To show the processes with the most shared memory, use top -o SHR -n 1.

System V shared memory

Finally it's possible you have some horrible legacy software that uses system V shared memory segments. If they get leaked, they won't show up in top :(.

You can list them with ipcs -m -t. Hopefully the most recently created one is still in use. Take the shmid number and e.g.

$ ipcs -m -t

------ Shared Memory Attach/Detach/Change Times --------
shmid      owner      attached             detached             changed             
3538944    alan       Apr 30 20:35:15      Apr 30 20:35:15      Apr 30 16:07:41     
3145729    alan       Apr 30 20:35:15      Apr 30 20:35:15      Apr 30 15:04:09     
4587522    alan       Apr 30 20:37:38      Not set              Apr 30 20:37:38     

# sudo grep 4587522 /proc/*/maps

-> then the numbers shown in the /proc paths are the pid of the processes that use the SHM. (So you could e.g. grep the output of ps for that pid number).

Apparent contradictions

Xorg has 8G mapped. Even though you don't have separate video card RAM. It only has 150M resident. It's not that the rest is swapped out, because you don't have enough swap space.
The SHM segments shown by ipcs are all attached to two processes. So none of them have leaked, and they should all show up in the SHR column of top (double-counted even). It's ok if the number of pages used is less than the size of the memory segment, that just means there are pages that haven't been used. But free says we have 6GB of allocated shared memory to account for, and we can't find that.