Page MenuHomeFreeBSD

service(8): add -s for showing status
Needs ReviewPublic

Authored by antranigv_freebsd.am on Sun, Nov 13, 11:36 PM.

Details

Reviewers
allanjude
0mp
Group Reviewers
manpages
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 48434
Build 45320: arc lint + arc unit

Event Timeline

allanjude added a subscriber: allanjude.

Reviewed-by: allanjude

This revision is now accepted and ready to land.Mon, Nov 14, 1:11 AM

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

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 requested changes to this revision.Mon, Nov 14, 9:53 AM

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.

This revision now requires changes to proceed.Mon, Nov 14, 9:53 AM
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.

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!

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

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()