I am using tmux version 2.7. What is a proper way to close all sessions so that there is no session at all running with tmux?
Any process running inside the session (such as a Rails server or Django server) should be terminated properly, without any of them dangling.
Ether of tmux kill-server or pkill tmux will do it (they have the same effect). All processes inside tmux will be sent SIGHUP by the kernel, what each does with it is up to the individual application.
I left out a very important part of this situation. The 'watch' command is part of a script that is scanning a series of hosts. The ssh sessions are created on the fly within the script. And there are several logs on each host that I'd like to watch. I've tried setting "ConnectTimeout=10" for instance to at least get it to move onto the next host but that doesn't affect how long it maintains the connection. Killing the ssh process seems to kill the script somehow.
Is there any way to use watch in an ssh session so that it only watches the target file for a set period of time before disconnecting? I know that you can use top in a batch manner and I'd like to be able to do the same thing with watch.
I don't see anything in the man pages and I haven't found anything in Internet searches where someone's been able to do this. Nor can I find an alternative to watch that can visually show changes to a file.
Any ideas?
You can simply kill the watch process after some time if that is all you need. If you run this as the command you pass to ssh so your ssh session will terminate when watch exits.
(sleep 3; kill `ps -C watch -o pid=`) & watch ls
I often have several tmux sessions running at the same time, in most of these sessions I will have a local server running on a port. What I want is to be able to automatically kill this server when detaching from a tmux session and similarly re-start the server when re-attaching.
Is there anything in tmux that makes this easier, it feels like if there was a hook that tmux provided so that you could run a script before the session was detached or reattached that would do the trick but I can't see anything like this in the docs.
Fast forward to 2017.
Today tmux has hooks called client-attached and client-detached that run when clients attaches to the session or detaches from it, respectively.
tmux a # attach most recent tmux session
or
tmux list-sessions # look for the session you want to kill
tmux a -t 0 # attach session named "0"
Once inside the session you want to kill:
[Ctrl]-B x # kill current pane of current session
Do that for all the panes and windows within that session and that should do it.
You could add something like this to your ~/.tmux.conf
shell-command /bin/bash yourhook.sh
This would at least give you some functionality when running tmux, but I'm not sure what you would do about a detach hook...
I am making an Asp.Net application which does the following on the client computer:
Establish a Connection
Check client's cpu usage to see if it is idle or not
if the client is idle it starts executing a c application
while executing the script if client starts doing something (also checked by monitoring his cpu usage) stop signal is sent
start signal is again sent to the client if he is back to his idle position
If the client is Ubuntu, I use ssh and execute what I want to. What is the way of doing this in Windows without the root access.
thanks in advance for replying.
This sounds a bit dodgy to me. However, what you are looking for is called PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553)
UPDATE
The only other way I can think of doing this is to use the built in task scheduler for windows.
With the task scheduler you can set a task to start when a computer has been idle for a particular amount of time and pause or stop it when it ceases to be idle.
Once the task is installed, just forget about it.
try SSH FTP or SFTP is analogous to SSH in windows
In a UNIX-y way, I'm trying to start a process, background it, and tie the lifetime of that process to my shell.
What I'm talking about isn't simply backgrounding the process, I want the process to be sent SIGTERM, or for it to have an open file descriptor that is closed, or something when the shell exits, so that the user of the shell doesn't have to explicitly kill the process or get a "you have running jobs" warning.
Ultimately I want a program that can run, uniquely, for each shell and carry state along with that shell, and close when the shell closes.
IBM's DB2 console commands work this way. When you connect to the database, it spawns a "db2bp" process, that carries the database state and connection and ties it to your shell. You can connect in multiple different terminals or ssh connections, each with its own db2bp process, and when those are closed the appropriate db2bp process dies and that connection is closed.
DB2 queries are then started with the db2 command, which simply hands it off to the appropriate db2bp process. I don't know how it communicates with the correct db2bp process, but maybe it uses the tty device connected to stdin as a unique key? I guess I need to figure that out too.
I've never written anything that does tty manipulation, so I have no clue where to even start. I think I can figure the rest out if I can just spawn a process that is automatically killed on shell exit. Anyone know how DB2 does it?
If your shell isn't a subshell, you can do the following; Put the following into a script called "ttywatch":
#!/usr/bin/perl
my $p=open(PI, "-|") || exec #ARGV; sleep 5 while(-t); kill 15,$p;
Then run your program as:
$ ttywatch commandline... & disown
Disowning the process will prevent the shell from complaining that there are running processes, and when the terminal closes, it will cause SIGTERM (15) to be delivered to the subprocess (your app) within 5 seconds.
If the shell isn't a subshell, you can use a program like ttywrap to at least give it its own tty, and then the above trick will work.
Okay, I think I figured it out. I was making it too complicated :)
I think all db2 is daemon-izing db2bp, then db2bp is calling waitpid on the parent PID (the shell's PID) and exiting after waitpid returns.
The communication between the db2 command and db2bp seems to be done via fifo with a filename based on the parent shell PID.
Waaaay simpler than I was thinking :)
For anyone who is curious, this whole endeavor was to be able to tie a python or groovy interactive session to a shell, so I could test code while easily jumping in and out of a session that would retain database connections and temporary classes / variables.
Thank you all for your help!
Your shell should be sending a SIGHUP signal to any running child processes when it shuts down. Have you tried adding a SIGHUP handler to your application to shut it down cleanly
when the shell exits?
Is it possible that your real problem here is the shell and not your process. My understanding agrees with Jim Lewis' that when the shell dies its children should get SIGHUP. But what you're complaining about is the shell (or perhaps the terminal) trying to prevent you from accidentally killing a running shell with active children.
Consider reading the manual for the shell or the terminal to see if this behavior is configurable.
From the bash manual on my MacBook:
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP
to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To
prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with
the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive
login shell exits.
which might point you in the right direction.