microsoft/wifi-ztp

ztpd exit code is always 0 regardless of exit condition

abeltrano opened this issue · 5 comments

Describe the bug
The ztpd daemon always returns a 0 exit code from its main process, regardless of whether the process exited cleanly or not. This is due to ztpd_run() having a void return type.

To Reproduce
Steps to reproduce the behavior:

  1. ztpd -c /path/to/ztpd/config.json -d
  2. kill -9 $(pidof -s ztpd)

Expected behavior
ztpd exits with a non-zero exit code.

Desktop (please complete the following information):

  • OS: Azure Percept Device
  • ztp v0.4.0.

The event_loop_run() return type needs to be changed from void to int, and the return value should indicate the status of the event loop. 0 should be returned from event_loop_run() if the event loop exited cleanly, otherwise, an appropriate negative errno value (eg. -EINVAL, -ENOSYS, etc.) should be returned.

The return value should be specified using the event_loop_stop() function. Its signature should be changed to:

int
event_loop_stop(struct event_loop *loop, int retval)

Where retval is the even loop return status to be returned from event_loop_run(). This value can then be propagated to event_loop_run() (probably through the struct event_loop context with a new field/member).

Do you want the error code to only be propagated if we enter on_signal_received, or should we have the error code from other events, like dpp_start, to also be propagated up to main?

`
on_signal_received(int fd, void *context)
{
struct signalfd_siginfo siginfo;
ssize_t bytes = read(fd, &siginfo, sizeof siginfo);
if (bytes < (ssize_t)(sizeof siginfo)) {
zlog_warning("siginfo read returned too little data");
return;
}

  switch (siginfo.ssi_signo) {
      case SIGINT:
      case SIGTERM:
          event_loop_stop((struct event_loop *)context);
          break;
      default:
          break;
  }

}
`

It looks like this is the only place where event_loop_stop is being used.

I think it makes sense to only propagate from where event_loop_stop is currently used since that is the only proper/expected way to stop the event loop.

Ok, so I only have to worry about if ztpd received a SIGINT or a SIGTERM for this issue right?

Ok, so I only have to worry about if ztpd received a SIGINT or a SIGTERM for this issue right?

Yep, seems like that's the only place where the event loop is stopped.