[PATCH v5 0/9] Fixes for early logging/prints and related cleanups
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case. v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical - add 9/8, taking care of a direct stderr print left-over v4: - in 4/8, name the new flag 'log_daemonised' instead of 'log_daemon_ready' v3: - add 2/8: we don't really need --stderr anymore - in 5/8, save errno at the beginning of the _perror() helper - in 7/8, avoid assigning errno to whatever return code we have just for the sake of using the new helpers: strerror() is actually less convoluted than that - add 8/8: there's no need to call __openlog() with a log file v2: - turn flag bitmap into simple, separate boolean flags - move errno description after message in _perror() functions - make some of the old perror() messages more descriptive *** BLURB HERE *** Stefano Brivio (9): conf, passt: Don't try to log to stderr after we close it conf, passt: Make --stderr do nothing, and deprecate it conf, log: Instead of abusing log levels, add log_conf_parsed flag log, passt: Always print to stderr before initialisation is complete log: Add _perror() logging function variants treewide: Replace perror() calls with calls to logging functions treewide: Replace strerror() calls conf, passt: Don't call __openlog() if a log file is used log: Don't report syslog failures to stderr after initialisation arch.c | 10 ++++----- conf.c | 41 ++++++++++++--------------------- fwd.c | 2 +- isolation.c | 46 ++++++++++++++++--------------------- log.c | 65 ++++++++++++++++++++++++++++++++--------------------- log.h | 25 +++++++++++++++++---- netlink.c | 4 ++-- passt.1 | 9 ++++---- passt.c | 64 +++++++++++++++++++--------------------------------- passt.h | 2 -- pasta.c | 27 +++++++++------------- pcap.c | 8 +++---- tap.c | 14 ++++++------ tcp.c | 24 +++++++------------- util.c | 12 +++++----- 15 files changed, 164 insertions(+), 189 deletions(-) -- 2.43.0
If we don't run in foreground, we close standard error as we
daemonise, so it makes no sense to check if the controlling terminal
is an interactive terminal or if --force-stderr was given, to decide
if we want to log to standard error.
Make --force-stderr depend on --foreground.
Signed-off-by: Stefano Brivio
The original behaviour of printing messages to standard error by
default when running from a non-interactive terminal was introduced
because the first KubeVirt integration draft used to start passt in
foreground and get messages via standard error.
For development purposes, the system logger was more convenient at
that point, and passt was running from interactive terminals only if
not started by the KubeVirt integration.
This behaviour was introduced by 84a62b79a2bc ("passt: Also log to
stderr, don't fork to background if not interactive").
Later, I added command-line options in 1e49d194d017 ("passt, pasta:
Introduce command-line options and port re-mapping") and accidentally
reversed this condition, which wasn't a problem as --stderr could
force printing to standard error anyway (and it was used by KubeVirt).
Nowadays, the KubeVirt integration uses a log file (requested via
libvirt configuration), and the same applies for Podman if one
actually needs to look at runtime logs. There are no use cases left,
as far as I know, where passt runs in foreground in non-interactive
terminals.
Seize the chance to reintroduce some sanity here. If we fork to
background, standard error is closed, so --stderr is useless in that
case.
If we run in foreground, there's no harm in printing messages to
standard error, and that accidentally became the default behaviour
anyway, so --stderr is not needed in that case.
It would be needed for non-interactive terminals, but there are no
use cases, and if there were, let's log to standard error anyway:
the user can always redirect standard error to /dev/null if needed.
Before we're up and running, we need to print to standard error anyway
if something happens, otherwise we can't report failure to start in
any kind of usage, stand-alone or in integrations.
So, make --stderr do nothing, and deprecate it.
While at it, drop a left-over comment about --foreground being the
default only for interactive terminals, because it's not the case
anymore.
Signed-off-by: Stefano Brivio
We currently use a LOG_EMERG log mask to represent the fact that we
don't know yet what the mask resulting from configuration should be,
before the command line is parsed.
However, we have the necessity of representing another phase as well,
that is, configuration is parsed but we didn't daemonise yet, or
we're not ready for operation yet. The next patch will add that
notion explicitly.
Mapping these cases to further log levels isn't really practical.
Introduce boolean log flags to represent them, instead of abusing
log priorities.
Signed-off-by: Stefano Brivio
After commit 15001b39ef1d ("conf: set the log level much earlier"), we
had a phase during initialisation when messages wouldn't be printed to
standard error anymore.
Commit f67238aa864d ("passt, log: Call __openlog() earlier, log to
stderr until we detach") fixed that, but only for the case where no
log files are given.
If a log file is configured, vlogmsg() will not call passt_vsyslog(),
but during initialisation, LOG_PERROR is set, so to avoid duplicated
prints (which would result from passt_vsyslog() printing to stderr),
we don't call fprintf() from vlogmsg() either.
This is getting a bit too complicated. Instead of abusing LOG_PERROR,
define an internal logging flag that clearly represents that we're not
done with the initialisation phase yet.
If this flag is not set, make sure we always print to stderr, if the
log mask matches.
Reported-by: Yalan Zhang
On Thu, Jun 20, 2024 at 06:15:13PM +0200, Stefano Brivio wrote:
After commit 15001b39ef1d ("conf: set the log level much earlier"), we had a phase during initialisation when messages wouldn't be printed to standard error anymore.
Commit f67238aa864d ("passt, log: Call __openlog() earlier, log to stderr until we detach") fixed that, but only for the case where no log files are given.
If a log file is configured, vlogmsg() will not call passt_vsyslog(), but during initialisation, LOG_PERROR is set, so to avoid duplicated prints (which would result from passt_vsyslog() printing to stderr), we don't call fprintf() from vlogmsg() either.
This is getting a bit too complicated. Instead of abusing LOG_PERROR, define an internal logging flag that clearly represents that we're not done with the initialisation phase yet.
If this flag is not set, make sure we always print to stderr, if the log mask matches.
Reported-by: Yalan Zhang
Signed-off-by: Stefano Brivio
Reviewed-by: David Gibson
--- log.c | 17 ++++++++--------- log.h | 1 + passt.c | 11 +++++------ 3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/log.c b/log.c index 05b7f80..0199eb4 100644 --- a/log.c +++ b/log.c @@ -33,7 +33,6 @@ static int log_sock = -1; /* Optional socket to system logger */ static char log_ident[BUFSIZ]; /* Identifier string for openlog() */ static int log_mask; /* Current log priority mask */ -static int log_opt; /* Options for openlog() */
static int log_file = -1; /* Optional log file descriptor */ static size_t log_size; /* Maximum log file size in bytes */ @@ -45,6 +44,7 @@ static time_t log_start; /* Start timestamp */
int log_trace; /* --trace mode enabled */ bool log_conf_parsed; /* Logging options already parsed */ +bool log_runtime; /* Daemonised, or ready in foreground */
void vlogmsg(int pri, const char *format, va_list ap) { @@ -70,7 +70,8 @@ void vlogmsg(int pri, const char *format, va_list ap) va_end(ap2); }
- if (debug_print || (!log_conf_parsed && !(log_opt & LOG_PERROR))) { + if (debug_print || !log_conf_parsed || + (!log_runtime && (log_mask & LOG_MASK(LOG_PRI(pri))))) { (void)vfprintf(stderr, format, ap); if (format[strlen(format)] != '\n') fprintf(stderr, "\n"); @@ -108,13 +109,15 @@ void trace_init(int enable) /** * __openlog() - Non-optional openlog() implementation, for custom vsyslog() * @ident: openlog() identity (program name) - * @option: openlog() options + * @option: openlog() options, unused * @facility: openlog() facility (LOG_DAEMON) */ void __openlog(const char *ident, int option, int facility) { struct timespec tp;
+ (void)option; + clock_gettime(CLOCK_REALTIME, &tp); log_start = tp.tv_sec;
@@ -135,7 +138,6 @@ void __openlog(const char *ident, int option, int facility)
log_mask |= facility; strncpy(log_ident, ident, sizeof(log_ident) - 1); - log_opt = option; }
/** @@ -156,20 +158,17 @@ void __setlogmask(int mask) */ void passt_vsyslog(int pri, const char *format, va_list ap) { - int prefix_len, n; char buf[BUFSIZ]; + int n;
/* Send without timestamp, the system logger should add it */ - n = prefix_len = snprintf(buf, BUFSIZ, "<%i> %s: ", pri, log_ident); + n = snprintf(buf, BUFSIZ, "<%i> %s: ", pri, log_ident);
n += vsnprintf(buf + n, BUFSIZ - n, format, ap);
if (format[strlen(format)] != '\n') n += snprintf(buf + n, BUFSIZ - n, "\n");
- if (log_opt & LOG_PERROR) - fprintf(stderr, "%s", buf + prefix_len); - if (log_sock >= 0 && send(log_sock, buf, n, 0) != n) fprintf(stderr, "Failed to send %i bytes to syslog\n", n); } diff --git a/log.h b/log.h index 3dab284..77d74a2 100644 --- a/log.h +++ b/log.h @@ -30,6 +30,7 @@ void logmsg(int pri, const char *format, ...)
extern int log_trace; extern bool log_conf_parsed; +extern bool log_runtime;
void trace_init(int enable); #define trace(...) \ diff --git a/passt.c b/passt.c index 19ecd68..e5cfd62 100644 --- a/passt.c +++ b/passt.c @@ -200,8 +200,8 @@ void exit_handler(int signal) int main(int argc, char **argv) { struct epoll_event events[EPOLL_EVENTS]; - char *log_name, argv0[PATH_MAX], *name; int nfds, i, devnull_fd = -1; + char argv0[PATH_MAX], *name; struct ctx c = { 0 }; struct rlimit limit; struct timespec now; @@ -225,7 +225,7 @@ int main(int argc, char **argv) strncpy(argv0, argv[0], PATH_MAX - 1); name = basename(argv0); if (strstr(name, "pasta")) { - __openlog(log_name = "pasta", LOG_PERROR, LOG_DAEMON); + __openlog("pasta", 0, LOG_DAEMON);
sa.sa_handler = pasta_child_handler; if (sigaction(SIGCHLD, &sa, NULL)) { @@ -240,7 +240,7 @@ int main(int argc, char **argv)
c.mode = MODE_PASTA; } else if (strstr(name, "passt")) { - __openlog(log_name = "passt", LOG_PERROR, LOG_DAEMON); + __openlog("passt", 0, LOG_DAEMON);
c.mode = MODE_PASST; } else { @@ -302,14 +302,13 @@ int main(int argc, char **argv) if (isolate_prefork(&c)) die("Failed to sandbox process, exiting");
- if (!c.foreground) - __openlog(log_name, 0, LOG_DAEMON); - if (!c.foreground) __daemon(c.pidfile_fd, devnull_fd); else pidfile_write(c.pidfile_fd, getpid());
+ log_runtime = true; + if (pasta_child_pid) kill(pasta_child_pid, SIGUSR1);
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
In many places, we have direct perror() calls, which completely bypass
logging functions and log files.
They are definitely convenient: offer similar convenience with
_perror() logging variants, so that we can drop those direct perror()
calls.
Signed-off-by: Stefano Brivio
perror() prints directly to standard error, but in many cases standard
error might be already closed, or we might want to skip logging, based
on configuration. Our logging functions provide all that.
While at it, make errors more descriptive, replacing some of the
existing basic perror-style messages.
Signed-off-by: Stefano Brivio
Now that we have logging functions embedding perror() functionality,
we can make _some_ calls more terse by using them. In many places,
the strerror() calls are still more convenient because, for example,
they are used in flow debugging functions, or because the return code
variable of interest is not 'errno'.
While at it, convert a few error messages from a scant perror style
to proper failure descriptions.
Signed-off-by: Stefano Brivio
If a log file is configured, we would otherwise open a connection to
the system logger (if any), print any message that we might have
before we initialise the log file, and then keep that connection
around for no particular reason.
Call __openlog() as an alternative to the log file setup, instead.
This way, we might skip printing some messages during the
initialisation phase, but they're probably not really valuable to
have in a system log, and we're going to print them to standard
error anyway.
Suggested-by: David Gibson
If we daemonised, we can't use standard error. If we didn't, it's
rather annoying to have all those messages on standard error anyway,
and kind of pointless too, as the messages we wanted to print were
printed to standard error anyway.
Signed-off-by: Stefano Brivio
On Thu, Jun 20, 2024 at 06:15:18PM +0200, Stefano Brivio wrote:
If we daemonised, we can't use standard error. If we didn't, it's rather annoying to have all those messages on standard error anyway, and kind of pointless too, as the messages we wanted to print were printed to standard error anyway.
Signed-off-by: Stefano Brivio
Reviewed-by: David Gibson
--- log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/log.c b/log.c index a72b871..9ed6bc1 100644 --- a/log.c +++ b/log.c @@ -191,7 +191,7 @@ void passt_vsyslog(int pri, const char *format, va_list ap) if (format[strlen(format)] != '\n') n += snprintf(buf + n, BUFSIZ - n, "\n");
- if (log_sock >= 0 && send(log_sock, buf, n, 0) != n) + if (log_sock >= 0 && send(log_sock, buf, n, 0) != n && !log_runtime) fprintf(stderr, "Failed to send %i bytes to syslog\n", n); }
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case.
v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical
Ah.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly. My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever. Regardless of that quibble, though, the semantics are substantially saner with this series than without so I'm happy to go ahead with it.
- add 9/8, taking care of a direct stderr print left-over
v4: - in 4/8, name the new flag 'log_daemonised' instead of 'log_daemon_ready'
v3: - add 2/8: we don't really need --stderr anymore - in 5/8, save errno at the beginning of the _perror() helper - in 7/8, avoid assigning errno to whatever return code we have just for the sake of using the new helpers: strerror() is actually less convoluted than that - add 8/8: there's no need to call __openlog() with a log file
v2: - turn flag bitmap into simple, separate boolean flags - move errno description after message in _perror() functions - make some of the old perror() messages more descriptive *** BLURB HERE ***
Stefano Brivio (9): conf, passt: Don't try to log to stderr after we close it conf, passt: Make --stderr do nothing, and deprecate it conf, log: Instead of abusing log levels, add log_conf_parsed flag log, passt: Always print to stderr before initialisation is complete log: Add _perror() logging function variants treewide: Replace perror() calls with calls to logging functions treewide: Replace strerror() calls conf, passt: Don't call __openlog() if a log file is used log: Don't report syslog failures to stderr after initialisation
arch.c | 10 ++++----- conf.c | 41 ++++++++++++--------------------- fwd.c | 2 +- isolation.c | 46 ++++++++++++++++--------------------- log.c | 65 ++++++++++++++++++++++++++++++++--------------------- log.h | 25 +++++++++++++++++---- netlink.c | 4 ++-- passt.1 | 9 ++++---- passt.c | 64 +++++++++++++++++++--------------------------------- passt.h | 2 -- pasta.c | 27 +++++++++------------- pcap.c | 8 +++---- tap.c | 14 ++++++------ tcp.c | 24 +++++++------------- util.c | 12 +++++----- 15 files changed, 164 insertions(+), 189 deletions(-)
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Fri, 21 Jun 2024 11:17:34 +1000
David Gibson
On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case.
v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical
Ah.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly.
My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever.
That's already the default, see pasta_start_ns(): if (!c->debug) c->quiet = 1; the problem is that if you want to debug something, and use a pasta shell (which is the most indicated way to debug something in most cases, I would say), you would usually pass --debug and a log file. Before and after this series (v5, but not v4), if you pass a log file, that debug output stays in the log file. If you don't give a log file, debug information will printed to stderr as usual. -- Stefano
On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote:
On Fri, 21 Jun 2024 11:17:34 +1000 David Gibson
wrote: On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case.
v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical
Ah.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly.
My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever.
That's already the default, see pasta_start_ns():
if (!c->debug) c->quiet = 1;
the problem is that if you want to debug something, and use a pasta shell (which is the most indicated way to debug something in most cases, I would say), you would usually pass --debug and a log file.
Oh... good point.
Before and after this series (v5, but not v4), if you pass a log file, that debug output stays in the log file.
If you don't give a log file, debug information will printed to stderr as usual.
I understand the choice in the short term, but this still doesn't feel quite right to me. I'm wondering if we should treat spawning a a pasta command as though we're going into the background. It's not in the Unix technical sense, but it is going to the background in the loose sense that pasta is no longer the thing that the user is primarily looking at on this terminal. But then, it would be nice to have a way to force output to stderr even with a pasta command - I find that pretty useful when debugging a specific problem, particularly when using a specific command rather than a shell. Maybe we could allow "-l -" or "-l stderr" or something with a special meaning? -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Mon, 24 Jun 2024 15:32:20 +1000
David Gibson
On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote:
On Fri, 21 Jun 2024 11:17:34 +1000 David Gibson
wrote: On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case.
v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical
Ah.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly.
My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever.
That's already the default, see pasta_start_ns():
if (!c->debug) c->quiet = 1;
the problem is that if you want to debug something, and use a pasta shell (which is the most indicated way to debug something in most cases, I would say), you would usually pass --debug and a log file.
Oh... good point.
Before and after this series (v5, but not v4), if you pass a log file, that debug output stays in the log file.
If you don't give a log file, debug information will printed to stderr as usual.
I understand the choice in the short term, but this still doesn't feel quite right to me.
I'm wondering if we should treat spawning a a pasta command as though we're going into the background. It's not in the Unix technical sense, but it is going to the background in the loose sense that pasta is no longer the thing that the user is primarily looking at on this terminal.
But then, it would be nice to have a way to force output to stderr even with a pasta command - I find that pretty useful when debugging a specific problem, particularly when using a specific command rather than a shell. Maybe we could allow "-l -" or "-l stderr" or something with a special meaning?
But that's already the case if you give --debug (or --trace) but no log file, isn't that enough? -- Stefano
On Mon, Jun 24, 2024 at 11:45:32AM +0200, Stefano Brivio wrote:
On Mon, 24 Jun 2024 15:32:20 +1000 David Gibson
wrote: On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote:
On Fri, 21 Jun 2024 11:17:34 +1000 David Gibson
wrote: On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
The most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case.
v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impractical
Ah.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly.
My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever.
That's already the default, see pasta_start_ns():
if (!c->debug) c->quiet = 1;
the problem is that if you want to debug something, and use a pasta shell (which is the most indicated way to debug something in most cases, I would say), you would usually pass --debug and a log file.
Oh... good point.
Before and after this series (v5, but not v4), if you pass a log file, that debug output stays in the log file.
If you don't give a log file, debug information will printed to stderr as usual.
I understand the choice in the short term, but this still doesn't feel quite right to me.
I'm wondering if we should treat spawning a a pasta command as though we're going into the background. It's not in the Unix technical sense, but it is going to the background in the loose sense that pasta is no longer the thing that the user is primarily looking at on this terminal.
But then, it would be nice to have a way to force output to stderr even with a pasta command - I find that pretty useful when debugging a specific problem, particularly when using a specific command rather than a shell. Maybe we could allow "-l -" or "-l stderr" or something with a special meaning?
But that's already the case if you give --debug (or --trace) but no log file, isn't that enough?
It's the case now, but wouldn't be if we treated spawning a pasta shell like going into the background, although that approach seems more sensible to to me in other ways. Eh, I can't quickly see a better way than what you have now, so never mind. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
participants (2)
-
David Gibson
-
Stefano Brivio