Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
Best regards,
Piotr Sikora piotr.sik...@frickle.com
Index: rc.subr
===
RCS
On Sun, 3 Apr 2011, Piotr Sikora wrote:
Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
No, this was left out on purpose. If you want to see stderr, use
RC_DEBUG.
Best regards,
Hi,
No, this was left out on purpose. If you want to see stderr, use
RC_DEBUG.
But this patch doesn't bring back stderr, it just prints
daemon(ok/failed).
This is already present in start, restart and stop commands, why
should reload be any different?
Best regards,
Piotr Sikora
On 2011/04/03 18:04, Piotr Sikora wrote:
Hello,
attached patch adds daemon(ok/failed) output to the reload command.
I believe it's extremely useful, since daemon's stderr is suppressed
by rc_do.
This doesn't usually indicate that the reload was successful,
just that you were able to send
On Wed, 6 Apr 2011, Piotr Sikora wrote:
Hi,
No, this was left out on purpose. If you want to see stderr, use
RC_DEBUG.
But this patch doesn't bring back stderr, it just prints daemon(ok/failed).
Ok but in your former mail you said since daemon's stderr is
suppressed So if you're
Hi,
This doesn't usually indicate that the reload was successful,
just that you were able to send the process a SIGHUP. As such I think
printing ok here gives a false sense of security.
Yes and no... Some daemons, like nginx, have custom rc_reload command that
actually does useful stuff and
Hi,
Ok but in your former mail you said since daemon's stderr is
suppressed So if you're looking for stderr, use RC_DEBUG.
What I meant is that since stderr is suppressed (we don't print daemon's
output), printing deamon(ok/failed) is the next best thing we can do to
inform users that
On Wed, 6 Apr 2011, Piotr Sikora wrote:
Hi,
Ok but in your former mail you said since daemon's stderr is
suppressed So if you're looking for stderr, use RC_DEBUG.
What I meant is that since stderr is suppressed (we don't print daemon's
output), printing deamon(ok/failed) is the
On Wed, 6 Apr 2011, Piotr Sikora wrote:
Hi,
Because it is next to impossible to get a correct return. By default,
all we can check is that SIGHUP was successfull or not, that's it.
Yes, but there are 8 ports that have custom rc_reload logic.
What does this have to do with
On 2011/04/06 15:09, Piotr Sikora wrote:
Hi,
Because it is next to impossible to get a correct return. By default,
all we can check is that SIGHUP was successfull or not, that's it.
Yes, but there are 8 ports that have custom rc_reload logic.
What does this have to do with
On Wed, 6 Apr 2011, Stuart Henderson wrote:
On 2011/04/06 15:09, Piotr Sikora wrote:
Hi,
Because it is next to impossible to get a correct return. By default,
all we can check is that SIGHUP was successfull or not, that's it.
Yes, but there are 8 ports that have custom
Hi,
Otherwise you can end up with
foobar(ok)
when in fact the daemon failed to reload.
We're ending up with $? = 0 from reload command anyway.
daemon(ok/failed) is only visual representation of that.
So we have to choose between hundreds of daemons that are using the
default or 8 that are
On Wed, 6 Apr 2011, Piotr Sikora wrote:
Hi,
Otherwise you can end up with
foobar(ok)
when in fact the daemon failed to reload.
We're ending up with $? = 0 from reload command anyway.
daemon(ok/failed) is only visual representation of that.
Exactly. But when I see a visual
Hi,
What about custom RC_RELOAD_OUTPUT variable that would print result for
ports
with custom logic? Would that work for you?
I would like to prevent adding knobs when at all possible.
To be honest, I kind of agree.
Last try:
What about printing only foobar(failed)? By definition, it
14 matches
Mail list logo
