"Weird Issue"

IRC, freenode, #hurd, 2013-07-01

<teythoon> oh, btw, there is this weird issue that I cannot figure out
<teythoon> I noticed that there is no newline printed by /hurd/init after
  printing " proc" and " auth"
<teythoon> but there *is* a printf("\n"); fflush(stdout); in there
<teythoon> it's just not working
<pinotree> iirc a newline is supposed to be printed after all the essential
  servers have been started
<pinotree> that one
<teythoon> yes
<teythoon> but this doesn't happen
<teythoon> for whatever reason printf("foo"); yields no output
<braunr> how are proc and auth printed ?
<teythoon> neither does printf("%s", "foo");
<teythoon> using printf
<teythoon> but printf("%i fooo", 4); works
<youpi> uh
<braunr> ??
<youpi> and does printf("loooooooooong line") worker?
<teythoon> no
<youpi> uh
<youpi> -er
<teythoon> and yes, the code is always fflushing stdout
<youpi> perhaps trying to put a sleep(1); to check for timing issues?
<teythoon> yes, I suspect something like that
<teythoon> b/c *sometimes* my hurd just freezes at this point
<braunr> ???
<teythoon> after printing proc auth and not printing the newline
<braunr> such horror stories .
<braunr> ..
<teythoon> and I *think* that putting more printfs there for testing
  purposes makes this worse, but I'm not sure about this
<braunr> in case you need to debug using printf, there is the mach_print
  system call
<braunr> (in -dbg kernels)

mach print.

<teythoon> what's wrong with using printf?
<braunr> you need to write the little assembly call yourself, where you
  intend to use it, because it's not exported by glibc
<braunr> printf is an RPC
<braunr> teythoon: RPCs are complicated stuff
<braunr> in particular in core glibc parts like signal handling
<youpi> and printf goes through the console translator
<braunr> also, if you don't yet have a console server available, it comes
  in handy
<youpi> better direct output directly to the kernel

stderr buffered

IRC, freenode, #hurd, 2011-11-06

<youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) {
  fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); }
<tschwinge> Isn't stderr in auto-flush mode by default?
<tschwinge> man setbuf: The standard error stream stderr is always
  unbuffered by default.
<youpi> tschwinge: "by default" is the important thing here
<youpi> in the case of translators iirc stderr is buffered
<tschwinge> youpi: Oh!
<tschwinge> That sounds wrong.

Logging

There have been several discussions and proposals already, about adding a suitable logging mechanism to translators, for example.

Decide / implement / fix that (all?) running (passive?) translators' output should show up on the (Mach / Hurd) console / syslog.

open issue documentation: id:"87oepj1wql.fsf@becket.becket.net"

open issue documentation: Neal once had written an email on this topic.

IRC, freenode, #hurd, 2011-11-23

<braunr> we'd need a special logging task for hurd servers
<pinotree> if syslog would work, that could be used optionally
<braunr> no, it relies on services provided by the hurd
<braunr> i'm thinking of something using merely the mach interface
<braunr> e.g. using mach_msg to send log messages to a special port used to
  reference the logging service
<braunr> which would then store the messages in a circular buffer in ram
<braunr> maybe sending to syslog if the service is available
<braunr> the hurd system buffer if you want