On 2022/12/29 17:51:48 +0100, Stefan Sperling <stsp@stsp.name> wrote:
> On Thu, Dec 29, 2022 at 04:48:31PM +0100, Omar Polo wrote:
> > On 2022/12/29 16:11:57 +0100, Stefan Sperling <stsp@stsp.name> wrote:
> > > On Thu, Dec 29, 2022 at 12:55:03PM +0100, Omar Polo wrote:
> > > > > +	switch (sig) {
> > > > > +	case SIGHUP:
> > > > > +		break;
> > > > > +	case SIGUSR1:
> > > > > +		break;
> > > > 
> > > > just for curiosity, what's the point of catching SIGUSR1 too?  the
> > > > listener process and gotwebd do that too (but gotwebd due to proc.c I
> > > > guess), but otherwise they don't do anything with it.
> > > 
> > > No idea. This was just copied along from other daemons.
> > > The HUP and USR signals are often used to trigger actions such as
> > > reloading config files. I suspect that is why they are present in
> > > all these signal handlers.
> > 
> > I see.  diff below drops it for gotd but I wouldn't mind to keep it
> > since it's there even in other daemons that don't do anything with it
> > (e.g. see relayd.)
> 
> The default action for USR1 is to terminate the process.
> Do we really want gotd to terminate when someone sends this signal?

wrote the patch in a hurry, i haven't thought it throughfully, sorry.
don't have a strong opinion either way to honest.  SIGUSR2 also
terminates the process by default, and it's not handled; on the other
way various daemons catch USR1 even if they don't do anything with it.

ignoring SIGUSR1 is not a burden anyway, so let's drop this.
Sorry for the noise.