Guess: through one of the files in /etc, rvm was being added to all shell sessions of the root user (including noninteractive ones). If your display manager or X server is started as root (typical), through a shell script (somewhat typical too), that could explain this behaviour. Restarting X (ctrl+alt+backspace, though some distros disable that by default) might then also have done the trick.
1 reply
I'm seconding what Thomas commented. Environment variables of newly created processes are (generally) inherited from the parent process. I'm not exactly sure about modern linux boot setups, but something like the following seems quite likely: When you first booted that day, the /etc/profile.d/rvm.sh file was still present, and set those variables in the environment that created your X session, window manager and the like. From there they were propagated into any new shells you started, even after the file had been removed from /etc/profile, since the variables were already set in some parent process, which was still running. As far as I know, there's no proper way of changing the environment variables of another process (attaching with gdb and poking in its innards does not count ;), so they stay in effect until the process ends -- which might have been accomplished by "only" logging out of the X session, but might as well really have required that reboot, depending on exactly where the variables are set in the boot process I handwaved about.
I tried this and it didn't work. I had to reboot. I tried to restart X, and then I couldn't log in. Weird.