My team at work manages a few thousand compute hosts for several thousand users. We have a system in place that allows users to open a terminal "somewhere" in the farm, and keeping the workload level is an important part of it. We depend on being able to to process accounting for each terminal process that is started.
It's common for users to ask for xterm, dtterm, and gnome-terminal processes. gnome-terminal presents a unique challenge for us. When you start a "new" gnome-terminal process, if you already have an "old" gnome-terminal process running in the same user session on the same machine, the "new" process passes the shell command on to the "old" process, and the shell/window are created as part of the "old" process tree; and the "new" process exits. This causes us to have problems with our process accounting, for obvious reasons.
This default behavior of gnome-terminal can be stopped by giving the --disable-factory option. But there's no way we can train all our users (8000+) to remember to use this option every time they ask for a gnome-terminal process in the farm. We need to find a way to lock this down so that gnome-terminal always behaves as if the --disable-factory option is given.
Is there a way to configure this for all users, site-wide? We'd prefer not to "wrap" gnome-terminal with a script to inject the option at invocation time, if possible-- that would work, but it's difficult to maintain, and it could be brittle. Adding a key in some /etc/gconf file would be ideal, but I'm not sure what (if any) key would be honored by gnome-terminal...?
Any advice would be appreciated! Thanks
The most painless way to do this would be using a configuration management tool to modify the gnome-terminal.desktop file to pass the --disable-factory option on the Exec= line. If you want to ensure this isn't affected by OS upgrades I think user specific .desktop files get processed before system ones, so copying this modified .desktop into either the local user's applications directory (or /etc/skel/) or moving the old one to a new different name might work.