Reputation: 6001
I wrote a script that has been running as a daemon for quite some time now. If I ever needed to debug it, I would stop the daemon version and rerun manually in current shell. I have never logged anything out of this script, but as I am getting ready to deploy it on a remote server I figured I want to log any errors that the script would get into. For that purpose I followed hints from several SO postings and am doing the following:
if ! tty > /dev/null; then
exec > >(/bin/logger -p syslog.warning -t mytag -i) 2>&1
fi
This seems to log just fine, I am just surprised to see two instances of my script listed by ps
when this feature is enabled. Is there a way to avoid it?
I know I get another process for logger
and I assume that it has to do with the >(...)
, but still hope to avoid it
Upvotes: 0
Views: 112
Reputation: 125708
bash spawns a subshell to execute the command(s) in >( ... )
. In this case, the only thing that subshell does is run /bin/logger
, so it's rather pointless. I think you can "fix" this with another exec command:
if ! tty > /dev/null; then
exec > >(exec /bin/logger -p syslog.warning -t mytag -i) 2>&1
fi
This doesn't prevent the subshell from starting, but then instead of running /bin/logger
as a subprocess (of the subshell), the subshell gets replaced with /bin/logger
. I haven't tested this with logger
, but it worked fine in a quick test I did with cat
and it seemed to work fine.
Upvotes: 3
Reputation: 37258
Look at the PPID column. (parent process), I think you'll see that the 2 processes are connected to each other.
Generally commands surounded by '( )' pairs indicate 'running-as-a-subprocess', hence 2 listings in ps because there are 2 copies of the process.
(I'm not familiar with the bash syntax exec > **${spaceChar}** >( .... ) 2>&1
, meaning the '>' seperated by a space from the 2nd '>' )
What is wrong with a crontab entry?
Upvotes: 0