Re: [PATCH v5 0/9] Fixes for early logging/prints and related cleanups

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2918 bytes --]

On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote:
> On Fri, 21 Jun 2024 11:17:34 +1000
> David Gibson <david@gibson.dropbear.id.au> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]