I have an old tmux session that when I open it via tmux a -t MySession it has a frozen width:
However, whenever I create a new tmux session, the width can be resized and such 'normally' -- the size only 'freezes' after exiting and re-entering:
Is there a way to prevent this, or to enable resizing the window once again, or do I literally have to delete the tmux session and re-create it to 'recapture' a flexible width?
Based on your <prefix>:list-clients output, you have other clients connected. These sessions can be other users on the system, or clients you accidentally kept active.
These others clients are what's causing tmux to be stuck in a smaller window size. tmux only allows the window size to match the smallest connected client, so that multiple users can access the client at the same time (which is a super useful feature that most people don't take advantage of).
If you don't care about sharing your sessions, you should switch the way you connect to tmux from -t <Session> to -dt <Session>. the -d will disconnect all other clients from your session, allowing your current client to be the only one setting the maximum dimensions.
If you want to disconnect individual clients, use <prefix> D (that's ShiftD, not just d), to view clients, and hit enter when you've highlighted the one you wish to disconnect.
Related
I'm working on a new container image that runs my worker process to drain an Azure queue. Once the queue is empty my app exits and I'd like the ACI to de-allocate and be removed as well. What I am seeing is the ACI stick around. It is in a "Terminated" state with a restart count of 0 as I would expect (seen in Azure Portal), but why is it not removed/deleted from the ACI list entirely?
I am using the Azure cli to create these instances and am specifying the restart never option. Here is my command line (minus the image specific details):
az container create --cpu 4 --memory 14 --restart-policy never --os-type windows --location eastus
I am of course also wondering where billing stops. Once I see the terminated state I am hoping that billing has stopped. Though this is unclear. I can of course manually delete the ACI and it is gone immediately, should exiting the app do the same?
If your container is in terminated state, you are no longer being billed. The resource itself though remains until you delete it though in the event you want to query the logs, events, or details of the container after termination. If you wish to delete existing container groups, writing some code on Azure Functions is a good route so you can define when something should be deleted.
Check out this base example of such a concept.
https://github.com/dgkanatsios/AzureContainerInstancesManagement/tree/master/functions/ACIDelete
Recently I found myself several times in situations where I need to let run some operation in some background xterm and I'd need to be notified when my input is requested.
I know how to make it so I'm notified when the command ends, but that doesn't help in the cases where the command is not 100% batch (it puts up a prompt every now and then; a common example would be apt-get) or where the command hangs (because of some network failure, for example).
So I'd like to be notified when there's been no output in the last N minutes. Is there some way to configure xterm to do that for me, or maybe some other tool (screen maybe) that could do it?
xterm doesn't notice if the application is actually waiting for input, or simply doing nothing. An application (or shell) could be modified to do this, but that seems like a lot more work than you expected (i.e., many programs could be modified).
I also don't know of a way how to do it for applications that might be waiting for input, but if you have a batch application that should always output log info within a certain time span then you could run an extra process that does the notification if it doesn't get killed within a timeout. The process gets killed whenever a new line is read. Maybe that will help you or someone else to adapt it to processes that might wait for input:
i=0;{ while true;do echo $i;((i++));sleep $i;done }|while read line;do if [ $pid ];then sudo kill $pid;fi;bash -c 'sleep 5;notify-send boom'& pid=$!;echo $line;done
The part before the pipe sign is a process that outputs slower and slower and if it becomes slower than the threshold, notify-send sends notifications. If you wanted output to happen within 3 minutes, use sleep 3m.
Not sure if this is possible but here it goes. I have a simple server set up where multiple clients could execute a program. Each time a client executes the script to start the program, a new instance of the program starts. Now when the client stops the program execution thru another script, the instance of the program is killed. The problem is if another client is on the server at the same time running the program that instance will be killed also. Is there any way to connect a particular instance to a particular client?
Here is more detail.
The server is used to stream media from the internet. I have streaming devices attached to tvs. When a particular channel is selected, it sends a signal to the server which in turn runs several scripts, one being a script to start a video conversion process thru program called ffmpeg. The ffmpeg coverts the stream, saves it to a folder on the server making it available to the streaming device/tv. Each time a user starts a channel, an instance of the ffmpeg starts because its converting a different stream. Once the user ends viewing, the device sends a signal back to the server thru php script, which in turn runs a script called cleanup. The cleanup script is a bat file that kills the ffmpeg and deletes the files that are no longer needed. All works great except if one individual elects to stop viewing while the other continues. I don't know how to tell the difference between each instance of ffmpeg. I don't want it to kill all instances just the one connected to the one particular stream that needs to end. I do have the capability of obtaining each device ip address when the user first selects the channel. Is there anyway to link the ip to the particular instance?
Actually took advice from above and renamed each instance as ip, stored ip in temp file, was then able to match it to the ip making the cancel call.
I want to open an ephemeral port, use it for a bit, close it --- but not allow any other processes to grab it --- and then open it again. This sequence of events allows me to test one network endpoint going down, and coming back up. In real life the port number would not be ephemeral.
I want to do this to test my network connectivity code. I'm running a large number of tests in parallel, and they use ephemeral ports to avoid conflicting with each other (and I'd rather not have a central directory of ports). My test is occasionally failing because it is unable to reacquire the same port, presumably because another test has grabbed it.
Just remember what it was and explicitly bind to it the second time. But you can't prevent anyone else grabbing it in between. Be quick ;-)
I am currently building a server using Debian Squeeze. It will be administered by myself and a friend, and I am wondering if it is possible to forward the output from ONE process to TWO clients.
As an example, process abc is running on the server. It uses X for graphical output. I would like to be able to view and control its X window on both client computers at the same time. This way, both my friend and I would be able to see the status of process abc and send commands to it from our remote computers. The only solutions that I have found so far indicate that the process can only connect to one X instance at a time, requiring that for me to see the X output, my friend would have to disconnect. Is there a way for both of us to connect and control the same process at the same time?
I am afraid that X forwarding allows only one connection. However, you can try VNC to achieve your desired setup.
You maybe able to use VNC to control the remote desktop (the (Archlinux Wiki) states that you maybe able to set x11vnc to forward the root desktop, which you both may be able to access at the same time; I haven't tried it so I can't say for certain).