Hot answers tagged background
The best way to do this is using screen, which keeps the session open in a persistent way even if the connection dies (and if you want to start using it again you can do a screen -r and it will open it up again). Prefixing whatever command you want to run with screen (eg. ssh -t user@host screen command) should do the job. If you want it to run in the ...
Answer found. For BASH, this depends on the huponexit shell option, which can be viewed and/or set using the built-in shopt command. Looks like this options is off by default, at least on RedHat-based systems. More info on the BASH man page: The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to ...
Are you looking to have a persistent session that you can resume, or just to stop a disconnect from killing the exection? For the former, use screen, for the latter, nohup.
It's important to note that while some processes take CTRL+Z to mean background, the default behavior is STOP, which does not continue execution. The safest way is to run the command with an & at the end, then run "disown" to force it to the background completely. You will not be able to foreground it again, however. If you want an easy way to keep an ...
Is my dev trying to milk me for more cash Maybe. It could also be that he is not familiar with your web host, and he isn't in a mood to try and figure it out. Hanlon's razor may apply here. Do I really need to switch hosting Maybe, you haven't really provided enough details. You probably need to get the developer to be more specific. Can ...
As mentioned early, screen can do all the trick. But not only what you need. I've use screen for the years and now use it every time I've login into systems. Try to install screen and create ~/.screenrc with such config: sessionname vcflists startup_message off deflogin off vbell off msgminwait 0 msgwait 10 log ...
Under bash, try: nohup ruby app.rb >> /log/file 2>&1 &
I agree with Warner and just want to add that you can keep the shell from sending SIGHUP with the builtin "disown" command. The bash man page contains a good description.
After you've used ^Z to STOP something, type "bg" to let it run in the background. "fg" will bring it back to front, as long as you haven't logged out.
The usual way is jobs. However, jobs doesn't see background processes which have been disowned, because they aren't attached to your shell any more. For those, you'll have to look at ps in some form or another, perhaps ps -u, depending.
screen -L -dmS somename ruby app.rb This will start a screen process with the name of 'somename', with all output from the program being logged to screenlog.0 in the current working directory. If you ever want to get back the application's console for some reason, you can do screen -r somename.
If your process can source whichever of /etc/profile or /etc/bash.bashrc and their respective $HOME files, then this might work for you: screen -d -m bash --init-file background-shell-script When "background-shell-script" exits, the screen session will be sitting waiting for you at a shell prompt when you reattach with screen -r. If you reattach before ...
They will show up in a pstree For example: pstree -a -h
You can use the command nohup to launch the command and redirect output into a nohup output file. From the nohup man page: nohup - run a command immune to hangups, with output to a non-tty The other option is to use the screen command. The benefit of using screen is that you can reconnect to the process later.
If you have access through cpanel then I dont see why he wouldn't be able to implement the cron jobs there. Unless he has a VPS with root access and for some reason runs the cronjobs as root, then I can see why he said that. Other than that, you should be able to stay with hostgator.
Deploying a service is more than being able to get it up and running, it's being able to keep it up and running and being able to automate processes. Humans entering stuff via a web UI is not scalable; insufficient access to the hosting to be able to check crontab is a sign that automation as a whole will be difficult. The developer might be so good that ...
When you fork a process into the background it will still be the child process from the shell executing it. All child processes running under a shell are sent a SIGHUP upon exit. Performance varies slightly depending upon the exact situation, which is detailed verbosely in bash's manpage. Other shells likely have similar descriptions. Apache, and other ...
To background commands just add & after the command.
I've seen this alternative to a reliable ssh "like" connection: http://mosh.mit.edu/
Known issue, however this should have been resolved in SP1: The "Desktop Wallpaper" Group Policy setting is not applied in Windows 7 or in Windows Server 2008 R2 http://support.microsoft.com/kb/977944 https://blogs.technet.com/b/deploymentguys/archive/2009/11/20/windows-7-rtm-issue-with-group-policy-enforced-wallpaper.aspx
Yeah... I have been in this same situation. I ended up writing a Windows service that would check for disconnected sessions using the API exposed in wtsapi32.dll, and then for each disconnected session, if the process I wanted wasn't running in that session, I'd use that person's token (which I can steal without needing to know that person's password, the ...
Try perl, the Swiss Army Chainsaw. Here's me finding the PID that holds port 80 open, then listing all the children: [me@lory ~]$ sudo netstat -apn|grep -w 80|grep LISTEN tcp 0 0 :::80 :::* LISTEN 8308/httpd [me@lory ~]$ ps -ef|perl -n -e '@j=split / */; print "@j" if ( @j==8308) ;...
There is a group policy that specifies walpaper (or background) and another one denying user from changing it Check user configuration - admin templates - desktop
Hm. If you're lucky, the ScreenHeight and ScreenWidth properties of the Win32_DesktopMonitor WMI class will be filled out on the client, which means you can easily use a VB script or Powershell script to determine the computer's desktop resolution. Get-WMIObject Win32_DesktopMonitor Now that you know the computer's resolution, you can set the appropriate ...
Add some options after your start: start /min cmd /c php -f 1.php ... This will suppress the additional command prompts.
You will find lots of very good information by reading Process Management. Also, take a look at your existing init.d scripts and use them as models as you write your own. Keep in mind though that some of them could stand improving. So try not to pick up any bad habits. You'll likely want to write your scripts in the Bourne shell (sh) rather than Bash, but ...
I would usually do: nohup mycommand & tail -f nohup.out
I have a severe opposition to allowing sudo level privilege escalation for your setup... Anywho: Toss 'sudo shutdown -h' into a script file. Then run at (scheduler) at -f /shutdown/script `date +%H:%M --date "now + 5 minutes"` Since you're using PHP it might make more sense to do the time calculation in PHP: $time = date('H:i', strtotime('+5 minutes')...
Only top voted, non community-wiki answers of a minimum length are eligible