I am running some code on the head node of a remote machine. Occasionally there is some issue and an infinite print out ensues. I try to ctrl-c but this doesn't seem to work.
If I then open a new terminal and look at top -u myusername this infinite process which I assume is taking up lots of CPU doesn't seem to appear.
My questions: (i) what is the best way to kill something like this when it happens? and (ii) why can't I see the runaway process in the top list.
Related
Mplayer provides shortcuts to change the track and play/pause the music but they only work if the mplayer window has the focus.
Is it possible, for example, to change the track currently played in mplayer with a command line? In that case, I could assign this command to a shortcut and use it even if mplayer does not have the focus.
All I found on google was how to use mplayer to play files or which shortcuts to change track when the window has the focus.
I am actually in the middle of trying to do this exact thing! I am going to share what I have discovered so far in case it helps anyone.
I have not been able to find a way to play/pause tracks. However, I have been able to change tracks, at least in terms of going to the next track.
I have found 2 ways so far: Using /proc/$pid/fd/0 and Named Pipes (FIFOs). Explaining FIFOs is a little harder (I just recently learned of them) so I will do that last.
Modifying STDIN via /proc/$pid/fd/0
We can communicate with a process in a different terminal session by redirecting input to the process' file definitions directory at /proc/$pid/fd/ where $pid is the process' PID.
Firstly, find the process ID using pidof. Make sure mplayer is actually running!
$ pidof mplayer
This will output the PID of mplayer. Using this $PID, we can input what we want to STDIN for mplayer by redirecting it to /proc/$PID/fd/0. (Note, 0 refers to STDIN, 1 to STDOUT, etc.). An example:
$ echo "p" > /proc/$PID/fd/0
This has the effect of changing the tracks for mplayer.
However, even though I used p in my example, I have found that you can echo anything (including nothing) and it will still accomplish the same goal of changing the track no matter what you input.
Named Pipes
Also called FIFOs, named pipes, just like regular pipes (|), redirect output to other processes. The main difference is that these are part of the filesystem and can be used to communicate between different terminal sessions.
To start off, create a new named pipe anywhere in your filesystem. I chose /tmp/.
$ mkfifo /tmp/mp3control.pipe
Then start mplayer redirecting its STDIN to the named pipe.
$ mplayer -playlist brutal_tunez.txt < /tmp/mp3control.pipe
It will look like the process hangs and that's because it is expecting the other side to input something.
Now open up a new terminal and input stuff into the pipe.
$ echo "p" > /tmp/mp3control.pipe
You will hear music start to play from mplayer. Again, just like before, any further inputs to the pipe will just change tracks.
I believe this has something to do with the way mplayer handles STDIN and is not the same thing as entering p to play or pause music.
I will continue looking into this but I would love to hear from someone if I made a mistake somewhere. All in all, this might end up being something where the amount of time spent is not worth it, to be honest. (But we still must!)
On my old system (Linux Mint 18.3), every time I used the less command and quitted (q), the last viewed page of less remained on the terminal (bash) view
On my new system (Min 19.3), when I quit 'less', everything fades, as if less was never opened (similar to what happens with 'nano' command, for example)
Is there a way to make less behave like in my old system? It was very useful when working e.g. with git logs
From man less:
-X or --no-init: Disables sending the termcap initialization and deinitialization strings to the terminal. This is sometimes desirable if
the deinitialization string does something unnecessary, like clearing the screen.
Assume I want to invoke a tool with a lot of options, like:
$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff
But the width of the terminal doesn't allow to have that thing on a "single line".
That alone isn't a problem, but with fish, there is a problem with scrolling.
When I enter that extra-wide command, at some point, there will be a line break:
$ somescript --option1 --option2 --option3 --option4 --option5
whatever even more stuff
All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.
The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.
Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.
In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.
This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.
Wrote up defect 6014 on github. Outcome is rather frustrating.
The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.
So, basically, when using fish on MacOs, option space is limited to:
use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.
And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.
Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!
I have started running a script on MATLAB that takes days to finish. Usually, if I changed my mind and I don't want wait for it to finish and I get content with the intermediate results, I highlight the command window and press Ctrl-C to break the code.
Now, I have run MATLAB. But its desktop got kinda stuck in the background. When I try to restore the desktop from the toolbar, it does not restore. But I know from the task manager that the process is running and is consuming Memory and CPU performance. So, I am kinda stuck. I don't want to kill the process because I need the intermediate values in the workspace, and I can't open the desktop to break the code using ctrl-c.
Is there any solution? For example, is there any command that can be used in the command prompt to act as ctrl-c for MATLAB?
I am using MATLAB R2012b and Windows 8.
Quick try to fix the recent Problem:
Try ty set a higher priority to matlab.exe in the Task Manager. (Right click -> Priority -> Higher than normal). Then see if you can get the window to front.
Some approaches to avoid this problem in future:
Try to optimize your code. For starters look at: http://de.mathworks.com/help/matlab/matlab_prog/vectorization.html
Use Matlab compiler for faster execution: http://de.mathworks.com/products/compiler/
Include some drawnow commands at stratetic positions in the code. This allows matlab to process the Event Queue and capture ctr-C commands.
Save intermediate results to output files. For example you could write an output file all 30 min with your intermediate results. Easyiest way would be just save(filename). Then a .matfile with all your workspace variables is generated. You can than kill the process in the task manager, without loosing too much results.
How can I execute a specific command automatically, when the cursor rests for a while?
During a correction phase of my project I very frequently run a grep on the word the cursor currently positioned on. I already found a great enhancement in Grep-o-Matic, which lets me execute a grep of the current word in my git repository. After re-assigning grep-o-matic-repository to F-12 I can execute the grep with one keystroke.
But maybe I could spare even this additional keystroke? I am thinking of a combination with something that wuould almost feel like the ispell-mode: When the cursor rests for, say, 500ms then the grep-o-matic-repository should be executed automatically.
As a final tweak the top 4 lines in the result windows should be removed, but that's a bonus I can probably attack later.