4 ms·
I used an exit trap to kill an SSH agent that I am running, and I noticed that dash did not kill if the script was interrupted, but only if it ran to successful
by chasil 3y ago
I used an exit trap to kill an SSH agent that I am running, and I noticed that dash did not kill if the script was interrupted, but only if it ran to successful completion.
I asked on the mailing list if this was expected behavior, and it turns out that POSIX only requires EXIT to run on a clean shutdown; to catch interruptions, add more signals.
trap 'eval $(ssh-agent -k)' EXIT INT ABRT KILL TERM
- js2 3y agoI think you want: trap 'ssh-agent -k' EXIT INT TERM I don't see any reason for the eval as "ssh-agent -k" doesn't return anything useful you want the shell to evaluate.
- chasil 3y agoThat's not what the eval is for. The "ssh-agent -k" command will emit shell commands that the shell must then execute which will kill the agent daemon and unset the socket environment variable.
- leodag 3y ago> The "ssh-agent -k" command will emit shell commands Does it really? I've executed it here and it just runs kill, doesn't emit any bash. Running just ssh-agent (without any args) does that though, which is what's probably causing the confusion.
- chasil 3y agoI am on OpenBSD 7.2, and I see: $ eval $(ssh-agent) Agent pid 56785 $ ssh-agent -k unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 56785 killed; The correct processing of that output requires an eval. Did you have any other questions?
- pmarreck 3y agoWhy do you need to eval it? $(ssh-agent) won’t substitute that with the stdout and run that?
- chasil 3y agoBecause the intended use for "ssh-agent -k" is for eval. While redirecting to /dev/null will certainly work, the agent is holding sensitive credentials (by design), and confirmation of shutdown has a tangible security benefit.
- js2 3y agoIf all you care about is killing it, you don't need to eval the output. The output just unsets two environment variables which only matters in the current shell context. $ ssh-agent SSH_AUTH_SOCK=/var/folders/8p/_pwq997168s7vdwwdg_qr1j40000gn/T//ssh-DE0IoJfU5rrM/agent.15015; export SSH_AUTH_SOCK; SSH_AGENT_PID=15016; export SSH_AGENT_PID; echo Agent pid 15016; $ SSH_AGENT_PID=15016; export SSH_AGENT_PID; $ ssh-agent -k unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 15016 killed; That said, it doesn't hurt to eval it, so I overstated my case in my original comment.
- diarrhea 3y agoHarsh lesson, those five signal names are identical if one squints real good. Would have never known.
- simcop2387 3y agoYou can't trap kill can you? doesn't that just go kill your process without any possibility of intervention or other actions? Also you probably want to handle HUP there too I would think (depending on what the script does)
- chasil 3y agoThat's what they put on the ticket, so that's what I'm using, but you're probably right.
- mike_hock 3y agoSIGABRT is also not a normal termination signal. Seems out of place here.
- paulddraper 3y agoSIGABRT would have to come from the process itself; IDK when if ever the shell would do that. And SIGKILL can't be handled, so that is indeed pointless.
- arp242 3y agoPOSIX says that "setting a trap for SIGKILL or SIGSTOP produces undefined results", but for signals it describes SIGKILL as "Kill (cannot be caught or ignored)". I'm guessing this is some relic from 80s Unix systems where SIGKILL behaved different, or perhaps just an inconsistency/oversight.
- deleted 3y ago[deleted]
- lgsymons 3y agoThe signals EXIT HUP INT TERM cover everything I've run into (I'm actually using EXIT SIGHUP SIGINT SIGTERM but presumably it's equivalent). In basic terms for my purposes these respectively account for a clean exit, the terminal emulator being closed, ctrl-c, the kill command (edit: the default SIGTERM kill -15, not the SIGKILL kill -9)
- thelastparadise 3y agoWhat's the signal for SIGKILL?
- EscapeFromNY 3y agoSIGKILL can't be handled. It's the signal you send when you don't want to give the process a chance to handle it.
- moehm 3y agoThat's the difference between kill -15 (SIGTERM) and kill -9 (SIGKILL), where SIGTERM shuts down a process gracefully.
- w-ll 3y agoRelevant: Monzy performs at Stanford Univ. "Kill Dash Nine" https://www.youtube.com/watch?v=Fow7iUaKrq4 https://www.youtube.com/watch?v=Fow7iUaKrq4
- shepherdjerred 3y agoThis is mandatory viewing
- chasil 3y agoI found my original submission to the email list. https://www.spinics.net/lists/dash/msg02208.html https://www.spinics.net/lists/dash/msg02208.html "Signal terminations are not caught by EXIT. It only catches normal exits. Unfortunately, the EXIT condition is not well-defined by POSIX, so it's left to interpretation." ... POSIX is making it unspecified what happens here: https://austingroupbugs.net/view.php?id=621 https://austingroupbugs.net/view.php?id=621 The EXIT condition shall occur when the shell terminates normally (exits), and may occur when the shell terminates abnormally as a result of delivery of a signal (other than SIGKILL) whose trap action is the default.
- usr1106 3y agoWhy do people write such standards? May occur. I don't need a standard to do something random.
- usr1106 3y agoI guess to get a well-defined behavior the interrupt handler needs to clear the EXIT trap.
- rigelina 3y agoIn this type of scenario, it's sometimes because there are two or more implementors that are trying to develop the standard in a way that makes their existing implementation compliant. Likely there were existing scripts that relied on the behavior being specific to that implementation, so it was explicitly made optional, which is viewed as better than not adding the behavior to the standard at all. "May" is just a polite standards way of saying "Warning: check yourself before you wreck yourself."
- jwilk 3y agoAnd now your script doesn't exit when you ^C it. It's a very common mistake with trap.