service jail start xyz returns success - when it shouldn't!

[Frank Leonhardt]

So I accidentally installed an ARM base system in a AMD64 jail and tried
to start it. It doesn't work, no one will be surprised to know.

The thing is I'd expect service to return non-zero if the jail it's
starting crashes and burns. To quote the FM:

" The service utility exits 0 on success, and >0 if an error occurs."

A pretty major error, but it still returns success. Now I can see why
this might be considered success - the "service" utility did what it was
told and the service itself went badly wrong. But it's not exactly
helpful if you want to know if your jail has started properly, is it?

My question - is this a bug, or can someone explain why it's actually a
feature?

Thanks, Frank.

[James Gritton]

The service in question is that of creating jails and starting them up.
So I'd call it one more layer removed: the service itself (creating a
jail) went fine. The jail was created and it reported success. Then
the jail's main process (presumably "sh /etc/rc") failed, so the jail
crashed and burned. But that's not the service; that's just whatever
the service was trying to do. The service reported back "OK, I've
readied by child for the world, and sent it out the door." That the
child took one step out the door and was hit by a bus is neither here
nor there.

From a practical standpoint, there's no good way to report the failure
of a jail. A successfully created jail runs for an arbitrarily long
time, and that is called success. Failure could happen immediately, or
it could also take a long time. Even if you choose to wait, jails have
no wait(2) call with an exit status like processes do. They're like
daemons that way; you have to judge success or failure on your own by
looking at logs, or seeing if what you expect to be running is in fact
still running.

- Jamie

[Frank Leonhardt]

Thanks. That's how I figured it too, which makes the return code as
useful as a chocolate teapot. I think most people would expect "service
start" to return success if the service was actually started, not that
an attempt to start it had been made. The service script returns the
result of an execv for the rc script. Looking at a few of the rc
scripts, some return a failure if they fail to start a service, others
return the return code of the final echo of the script (i.e. most likely
0). The jail script is one of these - it prints a "crashed and burnt"
message and then returns, by default, something likely to be 0.

The base system /etc/rc.d scripts do not seem to be consistent in how
they work or what they return at all, whereas the documentation
confidently states it will return a meaningful code. If this was a
"feature" then it would have to be consistent with the documentation, so
I'm putting it down as a bug (in the documentation or half the /etc/rc.d
scripts).

You make a good point that a jail (or any other service) might start and
then stop shortly afterwards by design. As this was ARM64 binaries, not
a single instruction was executed so I'd say that landed on the "failed"
side. But perhaps, as you suggest, it's not so easy to define total
success as a service can indeed start running and shut down due to an
error during initialisation and the script can't tell other than waiting
for, say, 15 seconds and checking it's still there.

For practical purposes, running "jls -j <jailname>" afterwards gives you
a valid success code if it has started - for anyone reading this in the
future and looking for an answer.

Regards, Frank.