Update
As mikemaccana notes, the systemd journal is now the standard logging device for most distros.
To view the stdout
and stderr
of a systemd unit use the journalctl
command.
sudo journalctl -u [unit]
Original Answer
By default stdout
and stderr
of a systemd unit are sent to syslog.
If you're using the full systemd, this will be accesible via journalctl
.
On Fedora, it should be /var/log/messages
but syslog will put it where your rules say.
Due to the date of the post, and assuming most people that are exposed to systemd are via fedora, you were probably hit by the bug described here:
https://bugzilla.redhat.com/show_bug.cgi?id=754938
It has a good explanation of how it all works too =) (This was a bug in selinux-policy that caused error messages to not be logged, and was fixed in selinux-policy-3.10.0-58.fc16
)
It's just that when stdout is not a terminal, output is buffered.
And when you press Ctrl-C, that buffer is lost as/if it has not been written yet.
You get the same behavior with anything using stdio
. Try for instance:
grep . > file
Enter a few non-empty lines and press Ctrl-C, and you'll see the file is empty.
On the other hand, type:
xinput test 10 > file
And type enough on the keyboard for the buffer to get full (at least 4k worth of ouput), and you'll see the size of file grow by chunks of 4k at a time.
With grep
, you can type Ctrl-D for grep
to exit gracefully after having flushed its buffer. For xinput
, I don't think there's such an option.
Note that by default stderr
is not buffered which explains why you get a different behaviour with fprintf(stderr)
If, in xinput.c
, you add a signal(SIGINT, exit)
, that is tell xinput
to exit gracefully when it receives SIGINT
, you'll see the file
is no longer empty (assuming it doesn't crash, as calling library functions from signal handlers isn't guaranteed safe: consider what could happen if the signal comes in while printf is writing to the buffer).
If it's available, you could use the stdbuf
command to alter the stdio
buffering behaviour:
stdbuf -oL xinput test 10 > file
There are many questions on this site that cover disabling stdio type buffering where you'll find even more alternative solutions.
Best Answer
Collating output together is not really the dual of
tee
.tee
makes multiple copies of its input, whereas collating output does not involve any merging of data.To merge output sources, just redirect them all to the same file descriptor. The interleaving of the sources is somewhat unpredictable in general, but sufficiently small writes to a pipe are guaranteed to be atomic. (Being able to tell the boundaries from the read side is another story.)
If you're getting input from multiple file descriptors and you want to merge them, pass each of them through.
But usually you'd be able to redirect all the file descriptors to the same destination.