summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/translator_stdout_stderr.mdwn
blob: 89efd4e12a1c158b6f7dc11e6a3b8aca36e5a85b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2013 Free Software
Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!toc]]


# "Weird Issue"

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

[[!tag open_issue_hurd]]

    <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)

[[microkernel/mach/gnumach/interface/syscall/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

[[!tag open_issue_hurd]]

    <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

[[!tag open_issue_hurd]]

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.

[[!taglink open_issue_documentation]]: [[!message-id
"87oepj1wql.fsf@becket.becket.net"]]

[[!taglink 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