29

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.

1

2 Answers 2

Reset to default
41

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

6
  • 2
    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.
    – mikeserv
    Apr 13, 2014 at 0:06
  • @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 ♦
    Apr 13, 2014 at 0:17
  • 1
    @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.
    – slm ♦
    Apr 13, 2014 at 0:21
  • 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.
    – mikeserv
    Apr 13, 2014 at 0:22
  • 2
    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.
    – mikeserv
    Apr 13, 2014 at 1:19
3

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .