Linux newbie here.
I have a perl script which takes two command line inputs. I tried to run it in the background but this is what I got:
[~user]$ nohup sudo ./ascii_loader_script.pl 20070502 ctm_20070502.csv &
[2] 19603
[~user]$ nohup: appending output to `nohup.out'
after the system returns "nohup: appending output to `nohup.out'", no new prompt will appear. Then as long as I type in some other command, the shell will tell me that the process is stopped:
[~user]$ nohup sudo ./ascii_loader_script.pl 20070502 ctm_20070502.csv &
[2] 19603
[~user]$ nohup: appending output to `nohup.out'
ls
ascii_loader_script.pl format_wrds_trd.txt nohup.out norm_wrds_trd.cfg
[2]+ Stopped nohup sudo ./ascii_loader_script.pl 20070502 ctm_20070502.csv
I've looked at this post and tried to do "sudo date" before executing the command. Still got the same thing.
http://www.sudo.ws/pipermail/sudo-users/2003-July/001648.html
The solution is to use the -b flag for sudo to run the command in the background:
$ sudo -b ./ascii_loader_script.pl 20070502 ctm_20070502.csv
You should only use nohup if you want the program to continue even after you close your current terminal session
The problem here, imho, is not nohup, but background processing sudo.
You are putting the process in background (& at end of command) but probably sudo needs password authentication, and that is why the process stops.
Try one of these:
1) remove the ampersand from end of command, reply to passord prompt and afterwords put it in background (by typing CTRL-Z - which stops the process and issuing the bg command to send it to background)
2) Change the /etc/sudoers to not ask for users password by including the line:
myusername ALL=(ALL) NOPASSWD: ALL
If besides the password reply your application waits for other input, then you can pipe the input to the command like this:
$ cat responses.txt|sudo mycommand.php
hth
You can Try
sudo su
and then
nohup ./ascii_loader_script.pl 20070502 ctm_20070502.csv &
instead of
nohup sudo ./ascii_loader_script.pl 20070502 ctm_20070502.csv &
You must use sudo first, nohup second.
sudo nohup ./ascii_loader_script.pl 20070502 ctm_20070502.csv &
My working solution for evaluating disk fragmentation in the background:
Exec sudo with nohup without ampersand (&) at the end:
$ sudo nohup nice -20 find / -type f -exec filefrag "{}" \; | sed 's/^\(.*\): \([0-9]\+\) extent.*/\2\t\1/'| awk -F ' ' '$1 > 0' | sort -n -r | head -50 > filefrag.txt
Enter password for sudo;
Press Ctrl+Z;
Put the running process in the background.
$ bg 1
[1]+ sudo nohup nice -20 find / -type f -exec filefrag "{}" \; | sed 's/^\(.*\): \([0-9]\+\) extent.*/\2\t\1/' | awk -F ' ' '$1 > 0' | sort -n -r | head -50 > filefrag.txt &
Now you can exit the terminal and log in later. The process will remain running in the background. Because nohup is used.
First of all, you should switch sudo and nohup.
And then:
if sudo echo Starting ...
then
sudo nohup <yourProcess> &
fi
The echo Starting ... can be replaced by any command that does not do much.
I only use it as dummy command for the sudo.
By this the sudo in the if-condition triggers the password-check.
If it is ok then the sudo session is logged in and the second call will succeed, otherwise the if will fail and not execute the actual command.
I open an editor and typed these lines:
#!/bin/bash
sudo echo Starting ...
sudo -b MyProcess
(Where MyProcess is anything I want to run as superuser.)
Then I save the file where I want it as MyShellScript.sh .
Then change the file permissions to allow execution.
Then run it in a terminal. the "-b" option tells sudo to run the process separately in the background, so the process keeps running after the terminal session dies.
Worked for me in linux-mint.
You can set it as your alias:
sudo sh -c 'nohup openvpn /etc/openvpn/client.ovpn 2>&1 > /dev/null &'
This should work
sudo -b -u userName ./myScript > logFile
I am just curious to understand that can I send this logFile as a email after the ./myScript is successful running in background.
Try:
xterm -e "sudo -b nohup php -S localhost:80 -t /media/malcolm/Workspace/sites &>/dev/null"
When you close xterm, the PHP web server still alive.
Don't put nohup before sudo or else the PHP web server will be killed after closing xterm.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the -c option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run sudo ls.sh. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with sudo -s then run your commands:
[nobody#so]$ sudo -s
[root#so]# ls -hal /root/ > /root/test.out
[root#so]# ^D
[nobody#so]$
Use sudo tee (if you have to escape a lot when using the -c option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to /dev/null is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>), use tee -a or tee --append (the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
The problem is that the command gets run under sudo, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with -c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
Arrange a pipe/subshell with required rights (i.e. sudo)
# Read and append to a file
cat ./'file1.txt' | sudo tee -a '/log/file.txt' > '/dev/null';
# Store both stdout and stderr streams in a file
{ command1 arg; command2 arg; } |& sudo tee -a '/log/file.txt' > '/dev/null';
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo or sh/bash
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT=\"YES\"\nIPADDR=10.42.84.168\nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>) to the target file rather than overwrite it (like >).
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
Don't mean to beat a dead horse, but there are too many answers here that use tee, which means you have to redirect stdout to /dev/null unless you want to see a copy on the screen.
A simpler solution is to just use cat like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo instead of the one running it.
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
This is based on the answer involving tee. To make things easier I wrote a small script (I call it suwrite) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
if [ $# = 0 ] ; then
echo "USAGE: <command writing to stdout> | suwrite [-a] <output file 1> ..." >&2
exit 1
fi
for arg in "$#" ; do
if [ ${arg#/dev/} != ${arg} ] ; then
echo "Found dangerous argument ‘$arg’. Will exit."
exit 2
fi
done
sudo tee "$#" > /dev/null
As shown in the USAGE in the code, all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a option to append, and also supports writing to multiple files at the same time.
echo test2 | suwrite -a /root/test.txt
echo test-multi | suwrite /root/test-a.txt /root/test-b.txt
It also has some simplistic protection against writing to /dev/ devices which was a concern mentioned in one of the comments on this page.
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the -c option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run sudo ls.sh. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with sudo -s then run your commands:
[nobody#so]$ sudo -s
[root#so]# ls -hal /root/ > /root/test.out
[root#so]# ^D
[nobody#so]$
Use sudo tee (if you have to escape a lot when using the -c option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to /dev/null is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>), use tee -a or tee --append (the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
The problem is that the command gets run under sudo, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with -c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
Arrange a pipe/subshell with required rights (i.e. sudo)
# Read and append to a file
cat ./'file1.txt' | sudo tee -a '/log/file.txt' > '/dev/null';
# Store both stdout and stderr streams in a file
{ command1 arg; command2 arg; } |& sudo tee -a '/log/file.txt' > '/dev/null';
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo or sh/bash
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT=\"YES\"\nIPADDR=10.42.84.168\nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>) to the target file rather than overwrite it (like >).
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
Don't mean to beat a dead horse, but there are too many answers here that use tee, which means you have to redirect stdout to /dev/null unless you want to see a copy on the screen.
A simpler solution is to just use cat like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo instead of the one running it.
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
This is based on the answer involving tee. To make things easier I wrote a small script (I call it suwrite) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
if [ $# = 0 ] ; then
echo "USAGE: <command writing to stdout> | suwrite [-a] <output file 1> ..." >&2
exit 1
fi
for arg in "$#" ; do
if [ ${arg#/dev/} != ${arg} ] ; then
echo "Found dangerous argument ‘$arg’. Will exit."
exit 2
fi
done
sudo tee "$#" > /dev/null
As shown in the USAGE in the code, all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a option to append, and also supports writing to multiple files at the same time.
echo test2 | suwrite -a /root/test.txt
echo test-multi | suwrite /root/test-a.txt /root/test-b.txt
It also has some simplistic protection against writing to /dev/ devices which was a concern mentioned in one of the comments on this page.
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
When I'm running command nohup sh script.sh & in Terminal I have the following output:
[1] 42603
appending output to nohup.out. Where 42603 is process id of this command, but I don't want to see it. What can I do?
P.S. I'm running OSX Capitan, version 10.11.6
You can run nohup in a subshell and redirect the subshell's output to /dev/null like this: (nohup sh script.sh &) >/dev/null (note that this will also hide any output from sh script.sh)
something like this will mute that one line and will keep the script.sh connected to stdout
nohup sh script.sh & | grep -v nohup.out
if it is outputting that thing to stderr you will need to redirect to stdout
nohup sh script.sh 2>&1 & | grep -v nohup.out maybe the order is wrong there, my shell scripting syntax is usually wrong
I am trying to execute the mvn plugin exec:java as a deamon on linux. When I do it "manually" from the console it seems to work:
$ nohup mvn -f $PATH_TO_POM exec:java -Pxyz &
launches the daemon and redirects the usual console output to the file nohup.out. I could not figure out what the -P parameter does, but I can use it to find the pid of the launches process and to kill the process
$ pgrep -f xyz # returns some pid, e. g. 12345
$ kill 12345
When I try to launch the daemon from within a simple bash script
# this is part of bash script in separate file
$ nohup mvn -f $PATH_TO_POM exec:java -Pxyz /tmp 2>> /dev/null >> /dev/null &
$ pgrep -f xyz # returns some pid, e. g. 12345
$ jps -l # shows that 12345 belongs to org.codehaus.plexus.classworlds.laucher.Laucher
$ jps -m # shows "12345 Launcher -f $PATH_TO_POM exec:java -Pxyz /tmp"
it fails, because after executing the file above and then
$ ps -p 12345
there is no such process with PID 12345, although the script above delivers the PID.
$ nohup mvn -f $PATH_TO_POM exec:java -Pxyz 2>> /dev/null >> /dev/null &
without /tmp works
I'm working on a script that will shred a usb drive and install Kali linux with encrypted persistent data.
#! /bin/bash
cd ~/Documents/Other/ISOs/Kali
echo "/dev/sdx x=?"
read x
echo "how many passes to wipe? 1 will be sufficient."
read n
echo "sd$x will be wiped $n times."
read -p "do you want to continue? [y/N] " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Yy]$ ]]
then
exit 1
fi
echo "Your role in the installation process is not over. You will be prompted to type YES and a passphrase."
sudo shred -vz --iterations=$n /dev/sd$x
echo "Wiped. Installing Kali"
sudo dd if=kali-linux-2.0-amd64.iso of=/dev/sd$x bs=512k
echo "Installed. Making persistence."
y=3
sudo parted /dev/sd$x mkpart primary 3.5GiB 100%
x=$x$y
sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sd$x
sudo cryptsetup luksOpen /dev/sd$x my_usb
sudo mkfs.ext3 -L persistence /dev/mapper/my_usb
sudo e2label /dev/mapper/my_usb persistence
sudo mkdir -p /mnt/my_usb
sudo mount /dev/mapper/my_usb /mnt/my_usb
sudo -i
echo "/ union" > /mnt/my_usb/persistence.conf
umount /dev/mapper/my_usb
cryptsetup luksClose /dev/mapper/my_usb
echo "Persistence complete. Installation complete."
It works nearly perfectly. These commands individually entered into the terminal will create the desired effect, but the problem comes in at line 37:
sudo echo "/ union" > /mnt/my_usb/persistence.conf
That command won't work unless I'm logged in as root user. To solve this I tried adding the sudo -i command before, but once I do that all of the following commands are skipped.
It's okay if the solution suggested requires me to type in the password. I don't want the password stored in the script, that's just wreckless.
Side note, I didn't make a generic form for this question because I want other people to be able use this if they like it.
The problem is that the echo runs with root privilege but the redirection happens in the original shell as the non-root user. Instead, try running an explicit sh under sudo and do the redirection in there
sudo /bin/sh -c 'echo "/ union" > /mnt/my_usb/persistence.conf'
The problem is that when you type in the following command:
sudo echo "/ union" > /mnt/my_usb/persistence.conf
Only the "echo" will be run as root through sudo, but the redirection to the file using > will still be executed as the "normal" user, because it is not a command but something performed directly by the shell.
My usual solution is to use teeso that it runs as a command and not as a shell built-in operation, like this:
echo "/ union" | sudo tee /mnt/my_usb/persistence.conf >/dev/null
Now the tee command will be run as root through sudo and will be allowed to write to the file. >/dev/null is just added to keep the output of the script clean. If you ever want to append instead of overwrite (e.g. you would be using >>normally), then use tee -a.