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.
Add DEBUG_SCRIPT=yes to pkg.conf and you have exactly that.
DEBUG_SCRIPTS=yes I do mean
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?
(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.
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).
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 :)
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.