I used to create a screen and use vim to trace source code.
I usually use the commands to create, detach and attach a screen to keep my vim status.
$ screen -S vim_src1
[CTRL+a] d to detach the screen
$ screen -r vim_src1
However, screen status will be killed after system restart.
Can I attach screen after system restart?
After a system restart there is no screen session to attach. You can certainly create a new session.
A screen session that you could attach has been running since you detached it. A system restart kills all of the processes (including those running in screen).
In desktop environments, you may see occasional support for saving "session" state. Doing that relies upon each application to save its state when asked, e.g., on system shutdown. That can be workable for large GUI applications (which are designed to handle events). But in contrast, screen is mostly used for shell applications where this is done rarely.
Rather than require each application to save/restore itself, it is conceivable that the operating system could be designed to do this. But that does not appear to be the case for the systems we are using.
Further reading:
How to Automatically Remember Running Applications from Your Last Session in Ubuntu 14.04
How can I keep restore for apps in Lion without having session restore when I log in?
I can interpret your answer in a few ways, because I'm not 100% certain what your objective is. I'll try to give the two most obvious options I'm aware of.
You can configure your screen session with ~/.screenrc so it always launches the same with, with labels and for screens, and it will even launch applications for you. For example:
defutf8 on
caption always "%{= kK} %{K}%-w%{+b w}%51>%n %t%{= K}%+w%<%-=%{= kK} me#localhost | %{w}20%y-%m-%d %{w}%0c:%s %{-}"
shelltitle '$|$'
defscrollback 10000
termcap xterm|xterms|xs ti=\E7\E[?47l
terminfo xterm|xterms|xs ti=\E7\E[?47l
startup_message off
screen -t vim 0 vim $HOME/todo.txt
screen -t ipython 1 ipython
screen -t finch 2 finch
screen -t mutt 3 mutt
screen -t top 4 top
chdir $HOME/Repos/git
screen -t CL 5
screen -t git 6
If you actually want to be able to save a session that you're in you might consider using screen-session.
https://github.com/skoneka/screen-session
Session saver currently supports saving of: layouts, scrollbacks,
titles, filters and is able to restart programs run in windows. It
recognizes regular, group and zombie windows. Currently there is no
support for serial and telnet window types. By default, session saver
also tries to save Vim sessions using ":mksession" and ":wviminfo".
Session saver accesses important data by directly reading /proc
filesystem and sorts processes by parent pid. There is almost no
"stuffing" of commands into windows (except when saving Vim sessions)
so there is no interaction with programs itself.
During session loading, every new window starts with
screen-session-primer (a small C program) which displays a list of
processes and asks user what to do: whether to start none, some or all
of window's processes or directly starts programs provided
"--force-start [win_num]" option was used.
Related
I spent several decades using Digital Equipment Corporation's VMS operating system, and one of the things I really miss is the terminal driver's 'read-with-prompt' functionality.
It would display the prompt and position the cursor for input, as you'd expect, but the prompt was immune to things like CTRL/U, CTRL/R, and CTRL/W. It was an attribute of the read operation, and every time the terminal driver was ready to read from the terminal with this option, it would show the prompt. The user couldn't erase it, so if it went off the screen he'd still know what was being requested.
This is one of the few things that I think VMS did better than U*X -- unless there's a Linuxish way of doing this.
So far I've never found it, but maybe I'm just not looking in the right place.
Is there a way on Linux to read from a tty with a persistent prompt?
Thanks!
I have a question about ulimit:
ulimit -u unlimited
ulimit -n 60000
If I execute these in a screen, will they forever be kept as a setting on the screen until I kill the screen or do I have to run it every time I run the program?
What I want to do is irrelevant, I just want to know if they will be kept as a setting within the screen.
ulimit is a bash builtin. It invokes the setrlimit(2) system call.
That syscall modifies some limit in its -shell- process (likewise the cd builtin calls chdir(2) and modifies the working directory of your shell process).
In a bash shell, $$ expands to the pid of that shell process. So you can use ps $$ (and even compose it, e.g. like in touch /tmp/foo$$ or cat /proc/$$/status)
So the ulimit applies to your shell and stay the same until you do another ulimit command (or until your shell terminates).
The limits of your shell process (and also its working directory) are inherited by every process started by fork(2) from your shell. These processes include those running your commands in that same shell. Notice that changing the limit (or the working directory) of some process don't affect those of the parent process. Notice that execve(2) don't change limits or working directories.
Limits (and working directory) are properties of processes (not of terminals, screens, windows, etc...). Each process has its own : limits and working directory, virtual address space, file descriptor table, etc... You could use proc(5) to query them (try in some shell to run cat /proc/self/limits and cat /proc/$$/maps and ls -l /proc/self/cwd /proc/self/fd/). See also this. Limits (and working directory) are inherited by child process started with fork(2) which has its own copy of them (so limits are not shared, but copied ... by fork).
But if you start another terminal window, it is running another shell process (which has its own limits and working directory).
See also credentials(7). Be sure to understand how fork(2) and execve(2) work, and how your shell uses them (for every command starting a new process, practically most of them).
You mention kill(1) in some comments. Be sure to read its man page (and every man page mentioned here!). Read also kill(2) and signal(7).
A program can call by itself setrlimit(2) (or chdir(2)) but that won't affect the limits (or working directory) of its parent process (often your shell). Of course it would affect future fork-ed child processes of the process running that program.
I recommend reading ALP (a freely downloadable book about Linux programming) which has several chapters explaining all that. You need several books to explain the details.
After ALP, read intro(2), be aware of existing syscalls(2), play with strace(1) and your own programs (writing a small shell is very instructive; or study the code of some existing one), and read perhaps Operating Systems: Three Easy pieces.
NB. The screen(1) utility manages several terminals, each having typically its shell process. I don't know if you refer to that utility. Read also about terminal emulators, and the tty demystified page.
The only way to really kill some screen is with a hammer, like this:
(image of a real hammer hitting a laptop found with Google, then cut with gimp, and put temporarily on my web server; the original URL is probably https://www.istockphoto.com/fr/photo/femme-daffaires-stress%C3%A9-%C3%A0-lordinateur-crash-arrive-et-d%C3%A9truisent-le-moniteur-gm172788693-5836585 and I understand the license permits me to do that.)
Don't do that, you'll be sorry.
Apparently, you are talking of sending a signal (with kill(1) or killall(1) or pkill(1) to some process running the screen(1) program, or to its process group. It is not the same.
This question is purely out of curiosity; there's no problem to be resolved.
Note: I'm using Konsole on CentOS 7.
When I SSH to a remote box and leave the session inactive for a while, it times out. As a workaround, I use less [some-file] to keep the session active.
Obviously the sessions still break when I suspend the VM at the end of the day.
The next day when I start a new SSH session, everything is normal except that some Konsole functionality doesn't work (namely, clearing scrollback, which I use a lot) for the same terminal window used for the SSH session.
However, after I less a file and quit, two things happen:
Konsole resumes working normally.
Whatever output was in the terminal before I used less is replaced with whatever output was there the previous day, before the session was broken by shutting down the VM I'm SSHing from.
Curiously, this happens for all ~4 concurrent terminals/sessions (each one having its output from the previous day restored). [edit: clarification: each of the ~4 terminals exhibits this behavior when I SSH/less in that particular terminal. Each one resumes its output from the day before. Doing this in one terminal/session is not affecting the other terminals/sessions]
I assume this would happen with any terminal app (e.g. vi, nano, etc.) with its own "gui" and isn't specific to less.
Seems like there's some caching going on. I assume quitting less (or vi, nano, etc.) triggers some sort of shell output restoration in general, but this particular manifestation seems somewhat odd.
Any idea what's going on?
The terminal feature described in the question the alternate screen feature (originally xterm, but copied/imitated by several other terminals including konsole). Depending on the terminal description, you may/may not use this feature.
less and most full-screen terminal programs such as vi send the escape sequences to switch to/from alternate screen if they're defined in the terminal description (i.e., TERM=xterm).
From the description, it sounds as if you're using different tabs in the same instance of konsole, and that it's remembering that your terminal was set to the alternate screen. konsole and some other programs attempt to save/restore "session" information when halted, so that probably seemed like a good thing to save/restore.
While in the alternate screen, terminal programs typically have little or no access to the scrollback region.
You can use tput to send the same escape sequence (without running less):
tput rmcup
(If the terminal description doesn't have a definition for that, it'll do nothing).
Further reading:
Why doesn't the screen clear when running vi?
So I want to run a program from my Desktop, but I would like to have my Desktop "forget it", so that if my Desktop crashes or shuts down it won't affect the SSH program.
In other words: I want the task to be executed on the remote computer independent of the computer, with which I'm sending the task.
Why would I wanna do this? Because I'm executing a huge task on a huge computer (64 cores computer), which should take days to evaluate, but I don't want my current computer to have to wait for it. The last time my Desktop froze, and I lost all the progress I had.
I can imagine that this question has been answered a million times already, but I don't know what terminology I have to search for, and I don't know what this process is called.
Thanks.
Some methods
Use nohup
Use Screen
Using Screen
Ubuntu : sudo apt-get install screen
screen
then after you lost ssh session.
login to ssh again and then
screen -r
This will resume ssh session screen.
For more info man screen
You could use (on the remote big iron) the batch(1) command since you want batch processing:
local% ssh remotebigmachine
remotebigmachine% batch << EOB
./myprog param1 param2 param3 > output.txt
EOB
remotebigmachine% exit
In the above both local% and remotebigmachine% are shell prompts (in practice they are something different).
BTW, for batch computation running many days, it is worthwhile to program some application checkpointing (because even supercomputers may have power outages or hardware issues).
On a computer with multiple monitors where the desktop is not shown on one of them, is there any way to draw on that monitor from a program?
Reasoning: I need to display a variable image full-screen on a separate monitor, without the user being able to disturb the screen with the mouse or without being able to shift windows on top of my image. Example: a computer has one monitor and one projector connected; the monitor shows a "normal" desktop and the projector shows the generated image (say, a color gradient).
The first use would be on Win7, but if a portable solution exists, an X11 solution under Linux would also be nice.
On Linux this is easy using xvfb, a virtual framebuffer. The command is:
Xvfb :1 -screen 0 1600x1200x32
You can run programs on the virtual screen by setting the environment variable DISPLAY=:1
The best part is the user doesn't even have to worry about interfering with the mouse or keyboard. Very useful for testing.
Under Linux, you can also run a second X session on the extra monitor
Xorg :1 -config /path/to/xorg_1.conf
But you'd need to write a xorg_1.conf configuration file to feed in.