Making scripts runs on backgourd and logging output

nohup bash 2>&1 | tee -i i-like-log-files.log &
Save all output to a log.

By: Tatsh
2015-09-02 06:07:11

1 Alternatives + Submit Alt

What Others Think

I didn't vote one way or another. You use the command nohup (a command immune to hangup signals) so the command will continue to run when you logout, but you usually you just need to put the command in the background with an & and it will keep running after you log out. I believe this is the default setting on most Linux distros and to be honest, I'm not sure where you set that. That is something I should look up for my own knowledge. Anyway, the alternatives provide more options for logging. I think you're just saying that if your script does logging it isn't going to stop if you run it this way? The tee example just writes to a file, so whatever is happening while you're logged out will be readable in the log file.
sonic · 315 weeks and 2 days ago
Here's the answer, recent versions of bash have sending an HUP child to all children processes turned off by default when you exit. Bash has an option huponexit that causes it to send SIGHUP to children when it exits, but it's not enabled by default. "An interactive login shell sends a SIGHUP to all jobs on exit if the huponexit shell option has been enabled (see Signals)." htp:// Basically, a big server like godaddy or 1and1 is probably going to have huponexit turned on, but you can get around it, by either running: unset huponexit at the end of your ~/.bash_profile file (if it gets called). You can manually run unset nohuponexit at any time when you're logged ini f necessary to make all jobs not get a HUP signal sent to them when you logout, but it would be more ideal to get you shell to call ~/.bash_profile so you don't have to remember to type it. Or you can just use nohup command keeping track of what you want to keep running when you logout or not. I'm the type of person who actually runs the jobs command before I logout, but if you forgot to run nohup on a command, it looks like you can just tell bash to not run kill -HUP against your pids.. I haven't tested this but it should work in theory. Also, if you ever forget to put a process in the background to start without typing & at the end, type Ctrl-Z and then bg. A command WILL almost always be killed if it's actively running and not in the background if you disconnect while it's running. I can't think of many exceptions.
sonic · 315 weeks and 2 days ago
Wow, they should let you edit your comments.. I just meant to say, " recent versions of bash having sending an HUP SIGNAL to all children processes turned off by default when you logout." There are some other mistakes but you can get the gist of what I'm trying to say at least..
sonic · 315 weeks and 2 days ago
great that i found this forum. People here are great. Learned alot. Keep posting more
Killersmile · 25 weeks and 5 days ago

What do you think?

Any thoughts on this command? Does it work on your machine? Can you do the same thing with only 14 characters?

You must be signed in to comment.

What's this? is the place to record those command-line gems that you return to again and again. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.

Share Your Commands

Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.


Subscribe to the feeds.

Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):

Subscribe to the feed for: