Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Following a tutorial on setting up gnupg to manage ssh keys I've managed to get several instances of gpg-agent running:

[root@frylock ~]# ps aux | grep agent
root      2764  0.0  0.0   4208   432 ?        Ss   11:15   0:00 ssh-agent
xtian     2785  0.0  0.1   3500   972 ?        Ss   11:18   0:00 gpg-agent -s --enable-ssh-support --daemon --write-env-file /home/frylock/xtian/.gnupg/gpg-agent.env
root      2958  0.0  0.0   3168   688 ?        Ss   11:39   0:00 gpg-agent -s --enable-ssh-support --daemon --write-env-file /root/.gnupg/gpg-agent.env
root      3036  0.0  0.0   4740   392 ?        Ss   11:43   0:00 gpg-agent --daemon
root      3186  0.0  0.0   4740   388 ?        Ss   11:53   0:00 gpg-agent --daemon
root      3299  0.0  0.0   4740   388 ?        Ss   11:58   0:00 gpg-agent --daemon
root      3549  0.0  0.0   4740   392 ?        Ss   12:54   0:00 gpg-agent --daemon

I can resolve most of this mess by going back over the instructions--a fifth time. But what I don't understand, why is my user account owner of a running process when I'm only logged in one tty as root?

share|improve this question
1  
A link to the tutorial you followed would be helpful. –  Joseph R. Sep 6 '13 at 21:34
    
Sure, First I followed gnupg, and then ssh keys. Why is this process listed if I exited xwindows back to the tty, logged out of all accounts and then logged back in as root? –  xtian Sep 6 '13 at 22:54
    
Processes can run in the background, and you don't have to be logged in. –  Paulo Almeida Sep 7 '13 at 0:29
    
Are you saying a process started from another user's .xinitrc is not killed when that user exits? If yes, then that's an answer I will accept (because I did not know this) –  xtian Sep 7 '13 at 14:53
1  
@xtian There is no intrinsic reason why a process started from .xinitrc would be killed when .xinitrc exits. A process can survive its parent, this happens all the time! As I explain in my answer, the reason GUI programs die when the session exits is that they're programmed to die when the X server goes away. –  Gilles Sep 13 '13 at 15:37

1 Answer 1

Generally speaking, logging out kills the applications that are connected to the means of interaction with the user. When you're logged into a text terminal (locally or remotely), all applications that are connected to that terminal are killed when you log out (directly by the kernel, or indirectly by the shell). When you're logged into a graphical environment, all applications that are connected to the X server are killed when you log out (or more precisely, the connection to the X server is severed, which causes most applications to exit).

Logging out doesn't kill all the processes started by a user. The user could want to leave programs running in the background, or could be logged into multiple sessions.

Applications such as ssh-agent and gpg-agent are not interactive, so they are not connected to any terminal or X server. A normal setup arranges for them to be killed by other means. Often the agent is the parent process of the whole session: the session startup scripts arrange to run something like ssh-agent $SHELL or ssh-agent $SESSION_MANAGER. That way, when the child process which is the session leader exits, the agent also exits (because that's how the agent is designed). If the agent is started differently, it's up to the session manager to arrange to kill it.

When you were experimenting while following that tutorial, you evidently started many agent processes in ways that the tutorial writer didn't expect, and they didn't die with your session. You can kill the ones you aren't using. Once you've reached a stable setup, check that the agent does get killed when you log out. (Unless you prefer to run a single agent and have it running permanently, which can be a reasonable choice on a personal machine.)

share|improve this answer
    
"Often the agent is the parent process of the whole session [...] the agent also exits..."; I was with you up to this last point. Suggesting the agent starts some processes and remains after it's child processes exit would explain the phenomena. This is confusing. –  xtian Sep 13 '13 at 13:45
1  
@xtian I don't understand your comment. When you call ssh-agent my-session-manager, the ssh-agent process starts my-session-manager, waits for it to exit, and then exits. The same goes for gpg-agent. If you have an agent that's still running, it's because you started the agent with no argument, which requires you to kill it explicitly, and for some reason you didn't kill it explicitly on logout. –  Gilles Sep 13 '13 at 15:06
    
"it's because you started the agent with no argument" == "because that's how the agent is designed"; Its a sort of clean-up pattern. The agent quits after all its toys are put away. –  xtian Sep 13 '13 at 15:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.