I did some remote work on a machine that I have infrequent access to and, at the end of my session, I issued sudo halt to terminate the connection and shut down the machine. Unfortunately, now I don't know whether or not the commands I used in the session were written to the .bash_history file. According to man halt it sends all running processes a SIGTERM and then a SIGKILL (I presume that it only does this if the process does not die in a timely manner):The halt and reboot utilities flush the file system cache to disk,  send all running processes a SIGTERM (and subsequently a SIGKILL) and,  respectively, halt or restart the system.I tested this out on my personal machine by first sending SIGTERM to bash, to which bash did not seem to respond. I then sent a SIGKILL, which obviously forced bash to die. I then checked the .bash_history file to see if anything was written there from my session, and nothing was. This makes sense to me since, according to my understanding, SIGTERM can be ignored by a process and it may perform its shutdown procedures as it desires since it can interpret how to respond to this signal. However, again according to my own understanding, SIGKILL may not be ignored and does not grant the process any time to perform clean-up or other dying rites.According to this test and the conclusions I came to from this test, it seems that it is quite unlikely that my remote session was saved when I issued sudo halt on the remote host. Is there some way I could be wrong about this and that my remote session was saved to .bash_history?
Does `sudo halt' give bash a chance to write its history?
bash;command history;shutdown
ssh killed by SIGTERMssh closes its pseudo-terminal (pty) master devicepty sends SIGHUP to bash.The shell exits by default upon receipt of a SIGHUP.https://stackoverflow.com/questions/5527405/where-is-sighup-from-sshd-forks-a-child-to-create-a-new-session-kill-this-chi