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:
ztpd -c /path/to/ztpd/config.json -d
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.