Bug 239144 - Identify generic RC framework extensions to improve ports script debugging
Summary: Identify generic RC framework extensions to improve ports script debugging
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: dogfood, feature, needs-qa
Depends on:
Blocks: 239124 239127
  Show dependency treegraph
 
Reported: 2019-07-11 15:43 UTC by Tara
Modified: 2019-08-02 13:46 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tara 2019-07-11 15:43:00 UTC
This is supposed to be a blocker bug for

#239126
#239127
#239124

to come up with a nicer/global way of handling figuring out why a port doesn't startup.

* Problem:

Right now, if a port/service doesn't start for whatever reason, other than sh -x  <rc script> one is sort of left out in the cold.  A lot of services that use daemon have the -f flag, which outputs to /dev/null which further complicates tracking down why some service didn't startup.

* Possible Solution

Have a service name debug command, that when run would set -x and redirect stderr/stdout from the service in question to the controlling tty.

This particular solution would likely require touching /usr/sbin/daemon and service.

Other/better thoughts and solutions are encouraged.

* Status

No patches or proof of concept(s) are created at this time.
Comment 1 Baptiste Daroussin freebsd_committer 2019-07-15 13:26:01 UTC
Add DEBUG_SCRIPT=yes to pkg.conf and you have exactly that.
Comment 2 Baptiste Daroussin freebsd_committer 2019-07-15 13:27:50 UTC
DEBUG_SCRIPTS=yes

I do mean
Comment 3 Pietro Cerutti freebsd_committer 2019-07-22 10:01:03 UTC
In bug #239124 and bug #239126 it is suggested to use a globally-overridable rc_daemon_output_flags variable to specify options to daemon(8) that are supposed to affect logging. If we want to have that, I'd rather have the default in the rc sources than in each port's startup script.

I understand that making the change in our rc framework first means that ports will have to wait before picking it up, but do we really want to replicate the default in several ports?
Comment 4 Kyle Evans freebsd_committer 2019-07-22 11:57:15 UTC
(In reply to Pietro Cerutti from comment #3)

The idea is to pitch it first and see if others find it acceptable. This will be the form that this stuff should get committed in later if the name/idea are found acceptable since it sets up the default the framework will be providing and it's easily greppable to remove once the framework provides the default in all supported versions.

It's not ideal, but this is likely the easiest way to later identify what needs fixed while allowing the framework to take over smoothly as changes propagate through.
Comment 5 Pietro Cerutti freebsd_committer 2019-07-22 12:01:10 UTC
I understand. Can we at least make a single sweeping commit of all ports that would benefit from it, so it's easier to track? If not, I'm fine with doing it piecemeal and I'll approve the change to fossil (bug #239126).
Comment 6 Tara 2019-07-22 13:53:22 UTC
Baptiste: all it does is add the -x for you, but does nothing for getting the output from the service executable yourself, and it's a GLOBAL flag, so once you set it, you get output from *every* service from then on.  I'm proposing a per-service debug, that works for figuring out why 1 particular service is being mean and not starting.

(In reply to Pietro Cerutti from comment #5)
1) I'm new to FreeBSD changes, I'm happy to do whatever is best.

2) I only did 3 ports, to sort of show off the idea, without expending lots of resources. If it's well accepted I'm happy to expend some more resources.

3) if we do it piecemeal, we get more chances at support across the ports tree and a better chance of finding where my idea will screw up long before it becomes default across the entire ports tree.  i.e. More ports people will see the commits against their particular port they maintain(or so I would think.. please tell me if I'm wrong).

Every port that uses daemon, doesn't necessarily do it the same way (these 3 I picked don't all run daemon the same way for instance).  A giant commit across the entire daemon using ports tree would be a lot of work all at once (since automating it would be difficult).  So piecemeal I can just push commits as I find a spare few minutes.

Also for services that don't use daemon(of which there are many), every single port will require some special unique fix I'm sure.  I haven't started looking at those yet.

I'd love to be proven wrong :)
Comment 7 Greg Veldman 2019-08-02 13:46:56 UTC
Some daemons can be quite verbose, and can be so long after startup.  Making a global change to redirect all that to syslog is actually a fairly significant functionality change, especially on small/embedded systems where the admin might not want all that extra info.

Maybe I'm being overly simplistic, but if you're having a problem with daemon startup, why not just look in the rc script, see what it's doing, then do that manually from your terminal with whatever levels of debug/verbosity/output redirection you find most appropriate?  The primary function of the rc framework is to be an automation tool, not a debugging tool, IMHO.  Which isn't to say making debugging easier is a bad thing, but rather if something like this is implemented on a large scale the defaults should probably reflect the current behavior, with the option for the local admin to change if desired.