Redefine signal handling flaws

Question

This is about the design decision and understand the procs and cons for adopting another service. So we have two services with two unrelated servers, one listening on port 10000 and another is a xinetd server responding 3 different requests via 3 different ports (its client uses nc server port1|port2|port3 to retrieve data).

One day because of the security issue, the xinetd server has to stop and just because the first server preserves the same data, we decided to adopt the xinetd server by sending USR1 signals to the first server and let it expose the same public data. Hence, there is a need to add logic to redefine the signal handling in the first server. We plan to use USR1 (10, 16, and 30) For example, in the xinetd server, kill -10 first_server will let the first server spit out the same data that the old server used to emit, and still dump to the first port. The argument is this is a bad design because it abuses the unix signal usage and of course redefined the POXIS and Linux pre-defined 10, 16, and 30 signum behavior. Is this really bad technically? What harm will make to the system?

Answer 1

10 is SIGBUS, a bus error -- you probably shouldn't touch that one. 30 and 31 are SIGUSR1 and SIGUSR2, which are user-defined and not reserved for any particular purpose. 16 is SIGURG, urgent data on a socket, which you might not need, but it would be better to use the real-time signals above 31.