A process isn't "killed with SIGHUP" -- at least, not in the strict sense of the word. Rather, when the connection is dropped, the terminal's controlling process (in this case, Bash) is sent a hang-up signal*, which is commonly abbreviated the "HUP signal", or just SIGHUP.
Now, when a process receives a signal, it can handle it any way it wants**. The default for most signals (including HUP) is to exit immediately. However, the program is free to ignore the signal instead, or even to run some kind of signal handler function.
Bash chooses the last option. Its HUP signal handler checks to see if the "huponexit" option is true, and if so, sends SIGHUP to each of its child processes. Only once its finished with that does Bash exit.
Likewise, each child process is free to do whatever it wants when it receives the signal: leave it set to the default (i.e. die immediately), ignore it, or run a signal handler.
Nohup only changes the default action for the child process to "ignore". Once the child process is running, however, it's free change its own response to the signal.
This, I think, is why some programs die even though you ran them with nohup:
- Nohup sets the default action to "ignore".
- The program needs to do some kind of cleanup when it exits, so it installs a SIGHUP handler, incidentally overwriting the "ignore" flag.
- When the SIGHUP arrives, the handler runs, cleaning up the program's data files (or whatever needed to be done) and exits the program.
- The user doesn't know or care about the handler or cleanup, and just sees that the program exited despite nohup.
This is where "disown" comes in. A process that's been disowned by Bash is never sent the HUP signal, regardless of the huponexit option. So even if the program sets up its own signal handler, the signal is never actually sent, so the handler never runs. Note, however, that if the program tries to display some text to a user that's logged out, it will cause an I/O error, which could cause the program to exit anyway.
* And, yes, before you ask, the "hang-up" terminology is left over from UNIX's dialup mainframe days.
** Most signals, anyway. SIGKILL, for instance, always causes the program to terminate immediately, period.
You’re asking several questions that aren’t necessarily related.
User processes run as the user. When the user signs out all those processes terminate.
Standby / hibernation / locking does not log a user out.
Some Windows applications save state and reopen after a reboot, making it possible to “resume” where you left off. Such as browser tabs.
VMs suspending are the same as a physical machine hibernating.
With that info you can deduce answers to all your different scenarios you asked about.
Best Answer
Almost all drivers run in kernel mode; they do not need an account, unless they start userspace processes. The few user-space drivers run under SYSTEM.
The login session, I can't check right now, but I'm sure it uses SYSTEM as well. You can see logonui.exe in Process Hacker or SysInternals ProcExp. In fact, you can see everything that way.
"Server software", see Windows services below.
There are three kinds here:
Plain old "background" processes. Those run under the same account as whoever started them, and do not run after logoff. The logoff process kills them all.
"HTTP, FTP servers, and other networking stuff" do not run as regular background processes. They run as services.
Windows "service" processes. Those are not launched directly, but via Service Manager. By default services run as LocalSystem (which isanae says equals SYSTEM), though they can have dedicated accounts configured.
(Of course, practically nobody bothers. They just install XAMPP or WampServer or some other crap, and let it run as SYSTEM, forever unpatched.)
On recent Windows systems, I think services can also have their own SIDs, but again I haven't researched this much yet.
Scheduled tasks. These are launched by the "Task Scheduler" service "in background", and always run under the account configured in the task (usually whoever created the task).
It's not a vulnerability because you must already have Administrator privileges to install a service. Having Administrator privileges already lets you do practically everything.
(see also various other non-vulnerabilities of the same kind)