Linux : how to redirect stdout & stderr to logger?

61,877

Solution 1

You need to combine the output of STDERR and STDOUT prior to piping it to logger. Try this instead:

/home/dirname/application_name -v 2>&1 | logger &

Example

$ echo "hi" 2>&1 | logger &
[1] 26818
[1]+  Done                    echo "hi" 2>&1 | logger

$ sudo tail /var/log/messages
Apr 12 17:53:57 greeneggs saml: hi

You can use the abbreviated notation here as well, if used cautiously in a actual Bash shell (not to be confused with Dash):

$ echo "hi" |& logger &

NOTE: This is equivalent to <cmd1> 2>&1 | <cmd2>. Again only use the above when making use of an actual Bash shell interactively, would be a good way to approach it.

excerpt from ABSG

# |& was added to Bash 4 as an abbreviation for 2>&1 |.

References

Solution 2

You could also log both stdout & stderr to different level in syslog.

{ ( echo info; >&2 echo critical ) 2>&3 | logger -t mycoolscript; } 3>&1 1>&2 | logger -t mycoolscript -p 2

The first part ( echo info; >&2 echo critical ) simulate a program that output both on stdout and stderr.

The trick with 2>&3 come from that answer, to be able to output stdout and stderr to different processes.

You could observe the result with journalctl -f with a Linux with systemd.

Share:
61,877

Related videos on Youtube

fred basset
Author by

fred basset

Engineer working with C, C++, assembler and embedded hardware.

Updated on September 18, 2022

Comments

  • fred basset
    fred basset over 1 year

    I have a program I need to run at startup, it has output on stdout and stderr that I want to redirect to the system log using the logger command. What I have in my startup script is thie:

    /home/dirname/application_name -v|logger 2>&1 &
    

    This is redirecting the stdout to syslog just fine but stderr is coming to the console, so I need to refine the command.

  • mikeserv
    mikeserv about 10 years
    slm, no offense meant, but the latter form is rampant bashism abuse. The amount of issues such unnecessary shorthand could cause are not at all worth what little gain could be had from their use. For instance, even just on your own machine, if you put the above in a script and dash tries to execute the script at boot only to fail and belly-up your boot process... well... When such syntax is mentioned it should always be in the context of interactive shells only, or, at least, such is my opinion.
  • slm
    slm about 10 years
    @mikeserv - no offense taken 8-). I include these since they're in the ABSG guide. I assumed (possibly incorrectly) that the OP was using Bash since they showed 2>&1 but your warns are quite wise, given the example is dealing with startups. I'll make those latter tips more prominent w/ a warning that they're meant for interactive only Bash shells.
  • slm
    slm about 10 years
    @mikeserv - nope it's sound advice. I generally don't use Dash or even Ubuntu so I'm a bit oblivious to these issues but they're still very real and it's good to point them out since Ubuntu/Debian/Dash is likely to be the more common scenario.
  • mikeserv
    mikeserv about 10 years
    I don't use debians either, honestly, but I'm becoming more and more aware that many do. I do use dash, though - it really is fast.
  • slm
    slm about 10 years
    @mikeserv - yeah I remember you mentioning that in chat one night. I'll have to spend a week trying to live in just Dash to gain a better appreciation of it.
  • mikeserv
    mikeserv about 10 years
    Well, that may not be necessary - you can't type fast enough for it to make a difference in an interactive shell - for which I use zsh. But, for scripts, dash is faster than any others I've tried.