SIGHUP probably does not mean what you think it does.
In the olden days (and I'm talking 1970s here), a terminal was a device that would connect to a UNIX machine over a serial line. This was often done through a modem connection, as in those days, getting a second machine was way more expensive than having to pay for a lot of phone connectivity; and by using a modem line, you could share a machine with someone far away.
When you're done using the machine, it was quite necessary to make sure that whatever you were running would be stopped, since machines back then did not have the same amount of resources that today's machines do, and hence the system would help you ensure you did not forget to do so by sending a signal to any processes connected to your serial line when the modem would hang up. This was the 'hangup' signal, the name of which got abbreviated to
At some point, someone figured out that it could sometimes make sense to have a process run continuously, so as to provide some service to the users on the machine. In order to make sure the process would indeed keep running, it was then necessary that it would be detached from the terminal on which it was started, so that when the user would disconnect and the modem would hang up, the process wouldn't be killed. Additionally, if the process would not detach from the serial line, then the terminal would not be released and the next user who tried to use it would not be able to do so. So for those reasons, you detach.
Now you have a long-running process which at some point might need to be reconfigured. You could restart it, or you could have the process poll its configuration file every so often. Both waste resources, however. It would be much better if you could tell it when to reread its configuration file. Since there's this one signal which for a daemon is meaningless anyway, why not just reuse that? Right, so that's what happened, and as z result a convention today is indeed for daemons to reread their configuration file when they receive
But that's only a convention, and it is by no means a general rule. The primary and documented purpose of
SIGHUP is still to signal the fact that the terminal connection has been severed. For that reason, the default action for any program upon receipt of the
SIGHUP signal is still to terminate, even if the process is a daemon.
As such, an
init implementation cannot just send
SIGHUP to random processes that it manages. Yes, in many cases the reload action does end up sending
SIGHUPto the daemon through whatever configuration the init system has (be that init scripts, systemd unit files, upstart configuration, or whatever); but it is incorrect to assume that this is what will always happen, and therefore if it's also incorrect to say that the two are equivalent.
Occasionally, this also explains why sending
SIGHUP to an
sshd in command of a terminal kills the session; it's because the sshd assumes something killed the connection, and that it therefore must terminate.