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