In the absence of a signal handler, does SIGTERM behave identically to SIGKILL

The process started by xterm will be the session leader in control of the terminal.

When the terminal goes away, that process automatically receive a SIGHUP signal (followed by a SIGCONT). This is sent by the kernel in a similar way that processes receive SIGINT when you press CTRL-C.

Additionally, a shell may send SIGHUP to some of its children upon exiting (see disown in some shells to disable that)

SIGKILL never fails to kill a running process, that's the point. Other signals exist to give the application a chance to react.

The default behavior of SIGINT, SIGTERM, SIGQUIT and SIGHUP is to kill the program. However applications are allowed to install a handler for these signals. So the actual behavior of applications when they receive these signals is a matter of convention (which each application may or may not follow), not of system design.

SIGINT is the “weakest” of the lot. Its conventional meaning is “stop what you're doing right now and wait for further user input”. It's the signal generated by Ctrl+C in a terminal. Non-interactive programs generally treat it like SIGTERM.

SIGTERM is the “normal” kill signal. It tells the application to exit cleanly. The application might take time to save its state, to free resources such as temporary files that would otherwise stay behind, etc. An application that doesn't want to be interrupted during a critical application might ignore SIGTERM for a while.

SIGHUP is about the same as SIGTERM in terms of harshness, but it has a specific role because it's automatically sent to applications running in a terminal when the user disconnects from that terminal (etymologically, because the user was connecting via a telephone line and the modem hung up). SIGHUP is often involuntary, unlike SIGTERM which has to be sent explicitly, so applications should try to save their state on a SIGHUP. SIGHUP also has a completely different conventional meaning for non-user-facing applications (daemons), which is to reload their configuration file.

SIGQUIT is the harshest of the ignorable signals. It's meant to be used when an application is misbehaving and needs to be killed now, and by default it traditionally left a core dump file (modern systems where most users wouldn't know what a core file is tend to not produce them by default). Applications can set a handler but should do very little (in particular not save any state) because the intent of SIGQUIT is to be used when something is seriously wrong.