Hey, Laslo!
I found what the problem was.
Well.. it wasn't really ME, but I helped.
Before I continue, let's quickly repeat the problem:
Inside of FreeBSD - I couldn't get Quark to redirect output (of incoming
connections) to a log file..
I tried 2>&1, >&, &>, >/dev/null and some combinations of those.. nothing
worked.
Before I copy-paste what others told me, I'll like to tell you what worked
for me:
https://stackoverflow.com/questions/3465619/how-to-make-output-of-any-shell-command-unbuffered
This.
I put that before I run Quark - and it logged/redirected output nicely to
a log file as expected.
Now to copy-paste what others said:
(on FreeBSD, someone else was trying to do the same thing (seems to be more
skilled than me, rtprio): getting Quark to output to a log file inside of a
FreeBSD jail)
...
<rtprio> daemon should really be able to grab it, yes
<rtprio> i don't know if it needs a fflush or what
<daemon> stderr is normally hot stdout is normally buffered in most
applications
...
<daemon> that means stdbus is called in the child
...
(what we agreed that works)
daemon -o /tmp/quark stdbuf -i0 -o0 -e0 quark -p 8000 -d /tmp -l
...
<daemon> it was quarks faul
<daemon> t
<daemon> if it was before daemon it was daemon's fault
<daemon> if it was within daemons exec child it was quarks
<rtprio> daemon detaches so that doesn't make any sense
<rtprio> of course it wouldn't have stderr open
<daemon> if its on the inside of what daemon starts, the only thing buffering
writes can be the child
<daemon> because that is all you changed
<daemon> by having stdbug inside, the child daemon created got told it has no
buffers
...
P.S. yes - it's a coincidence that the user is also named 'daemon'.
Now there's no need to feel sad about the "it was quarks fault" - we all
learn
something new pretty much every day (if we want to learn, that is).
I am just fucking happy I got my gucchi server of choice (Quark) to work as I
want it.
I hope I helped :) sorry I didn't add an patch as well xD
Received on Thu Jan 05 2023 - 20:02:48 CET