service(8): add -s for showing status

[antranigv_freebsd.am]

Summary

You can do -s to show status for all services all use -es to show status for enabled services. -s does not do a blind run, first it checks if the service does provide a status command.

[allanjude]

Reviewed-by: allanjude

[lwhsu]

Don't forget to modify usr.sbin/service/service.8 :)

[bcr]

Quick question: some of the if-statements here are wrapping the check into [], while others do not.
Do we have some kind of style-guide for shell scripts like this for consistency?
Nothing against the change per se, just wondering.

[0mp]

Thanks for the patch!

Apart from the missing manual page update (which is an easy fix!) I'm not sure if the presented implementation works for all the rc.d scripts though. It seems fine for the well-behaved simple service scripts (like DB daemons or web servers), but it is going to return unexpected results for one-off rc scripts like zfskeys or ipfw_netflow I think. The problem is that some service scripts (ab)use the status subcommand to return interesting information related to that service.

As of now, the description of status in rc(8) is not very precise.

I believe a way forward here is:

1. Document what do we mean by "running". Ideally, we would define that as "the service has a process running and service onestatus exits with 0`. However, there are some services which exit with 0 and do not have a running userland process, so this is not perfect. At the same time, perhaps a new subcommand called "isrunning" that would default to "status" for the daemon-like services?
2. Fix the rc scripts (at least in base) to follow the new definition of "running"
3. Extend service(8) with the suggested functionality.

That would be my idea of going forward. I'd like to hear your thoughts, @antranigv_freebsd.am :)

usr.sbin/service/service.sh

53

Could you sort the flag list?

56

Would be nice to keep this list sorted.

[0mp]

In D37383#849582, @bcr wrote:

Quick question: some of the if-statements here are wrapping the check into [], while others do not.

@bcr, [ is not a style thing. It is an alternative name of the test program. See man [, which is the same as man test.

[antranigv_freebsd.am]

In D37383#849570, @lwhsu wrote:

Don't forget to modify usr.sbin/service/service.8 :)

Will do!

In D37383#849582, @bcr wrote:

Quick question: some of the if-statements here are wrapping the check into [], while others do not.
Do we have some kind of style-guide for shell scripts like this for consistency?
Nothing against the change per se, just wondering.

Style-guide-wise, I don’t think that we do. Even complex shell scripts use multiple styles for testing. I’ll have to check style again.

In D37383#849599, @0mp wrote:

Thanks for the patch!

Apart from the missing manual page update (which is an easy fix!) I'm not sure if the presented implementation works for all the rc.d scripts though. It seems fine for the well-behaved simple service scripts (like DB daemons or web servers), but it is going to return unexpected results for one-off rc scripts like zfskeys or ipfw_netflow I think. The problem is that some service scripts (ab)use the status subcommand to return interesting information related to that service.

As of now, the description of status in rc(8) is not very precise.

I believe a way forward here is:

1. Document what do we mean by "running". Ideally, we would define that as "the service has a process running and service onestatus exits with 0`. However, there are some services which exit with 0 and do not have a running userland process, so this is not perfect. At the same time, perhaps a new subcommand called "isrunning" that would default to "status" for the daemon-like services?
2. Fix the rc scripts (at least in base) to follow the new definition of "running"
3. Extend service(8) with the suggested functionality.

That would be my idea of going forward. I'd like to hear your thoughts, @antranigv_freebsd.am :)

1. Totally agree, for example, even in base the routing service would return the routing table with exit code 0. While personally I’m okay with that for the time being, I think you’re right, we either need a new subcommand, or we need to break these scripts to NOT return such things.
2. This seems easy, just a bit of mechanical work.
3. Hopefully with a man page :)

So, how does this go forward? First we add the isrunning subcommand that defaults to status, unless specified? Or do we modify the base rc.d scripts to exclude the status subcommand?

Jail is also a good example. service jail status basically runs jls. Do we tell rc.d/jail to not run the status command? Maybe isrunning can print all the jail names and we paste that into the output? While other services (like sshd) would print running?

I get confused very easily :) let me know!

[antranigv_freebsd.am]

make sure that zfskeys, ip6addrctl, jail and ipfw_netflow return non-zero when not running

[antranigv_freebsd.am]

usr.sbin/ip6addrctl/ip6addrctl.c

122

FYI: this is technically wrong. because no error occurs. The other options is for get_policy to return an int and use that int in exit()

[0mp]

Hey, I've not got the time to review the changes yet.

Here's an interesting bit of Ansible, though. It's an example of a software running on FreeBSD and using onestatus to get the information about whether a service is running or not. The most interesting bit is perhaps that pf requires a special case there: https://github.com/ansible/ansible/blob/v2.14.1/lib/ansible/modules/service.py#L1027-L1035