12-19-2019, 02:49 AM
Make sysadmin work on Fedora easier with screen
<div><p>When you manage a Linux instance, you’ll find that your job is made much easier by the many tools designed specifically to deal with something specific within the system. For example, if you need to install packages, you have easy-to-use package managers that make that a breeze. If you need to create, resize or delete filesystems, you can do so using tools that are built to be used by humans. The same goes for managing services and browsing logs with <a href="https://fedoramagazine.org/what-is-an-init-system/">systemd</a> using the <em>systemctl</em> and <em>journalctl</em> commands respectively. The <em>screen</em> tool is another such example.</p>
<p>You can run all of those tools directly at the command line interface. But if you’re connecting to a server remotely using SSH, sometimes you need another layer between you and the operating system so the command you’re running doesn’t stop if your remote connection terminates. Sysadmins do this to prevent sudden termination in case of a connection issue, but also on purpose to run a command that needs to keep running indefinitely in the background. Enter the <em>screen</em> utility.</p>
<p> <span id="more-29819"></span> </p>
<h2>Introducing screen</h2>
<p>The <em>screen</em> tool allows you to have multiple sessions (called <em>screens</em>) that are independent from each other and that you can name, leave and join as you desire. It’s multi-tasking for the remote CLI. You can get started with it simply by running this command:</p>
<pre class="wp-block-preformatted">$ screen</pre>
<p>The command creates a screen and connect you to it: your current session is now a screen. You can run any command that does something and doesn’t automatically terminate after a few seconds. For example, you might call a web app executable or a game server. Then press <strong>Ctrl+A</strong> and, right after that, the <strong>D</strong> key and you will <em>detach</em> from the screen, leaving it running in the background.</p>
<p>The <strong>Ctrl+A</strong> combination, given that it is part of every <em>screen</em> command, is often shortened in documentation to <strong>C-a</strong>. Then the <em>detach</em> command used earlier can be described simply as <strong>C-a d</strong>. </p>
<h3>Getting in and out of sessions</h3>
<p>If you want to connect to that screen again, run <em>screen -r</em> and you will <em>attach</em> to that screen. Just running <strong>screen</strong> will create a new screen, and subsequent <em>screen -r</em> commands will print out something like this:</p>
<pre class="wp-block-preformatted">There are several suitable screens on: 5589.pts-0.hostname (Detached) 5536.pts-0.hostname (Detached) Type "screen [-d] -r [pid.]tty.host" to resume one of them.</pre>
<p>You can then choose whether to resume the first or the second screen you created by running either one of these commands:</p>
<pre class="wp-block-preformatted">$ screen -r 5536
$ screen -r 5589</pre>
<p>Adding the rest of the name of the string is optional in this case.</p>
<h3>Named screens</h3>
<p>If you know you’ll have multiple screens, you might want to be able to connect to a screen using a name you choose. This is easier than choosing from a list of numbers that only reflect the process IDs of the screen sessions. To do that, use the <em>-S</em> option as in the following example:</p>
<pre class="wp-block-preformatted">$ screen -S mywebapp</pre>
<p>Then you can resume that screen in the future using this command:</p>
<pre class="wp-block-preformatted">$ screen -r mywebapp</pre>
<h3>Starting a process in the background using screen</h3>
<p>An optional argument is the command to be executed inside the created session. For example:</p>
<pre class="wp-block-preformatted">$ screen -S session_name command args</pre>
<p>This would be the same as running:</p>
<pre class="wp-block-preformatted">$ screen -S session_name</pre>
<p>…And then running this command inside the <em>screen</em> session:</p>
<pre class="wp-block-preformatted">$ command args</pre>
<p>The screen session will terminate when the command finishes its execution.</p>
<p>This is made particularly useful by passing the <strong>-dm</strong> option, which starts the screen in the background without attaching to it. For example, you can copy a very large file in the background by running this command:</p>
<pre class="wp-block-preformatted">$ screen -S copy -d -m cp /path/to/file /path/to/output</pre>
<h2>Other screen features</h2>
<p>Now that you’ve seen the basics, let’s see some of the other most commonly used screen features.</p>
<h3>Easily switching between windows in a screen</h3>
<p>When inside a screen, you can create a new window using <strong>C-a c</strong>. After you do that, you can switch between the windows using <strong>C-a n</strong> to go to the next one and <strong>C-a p</strong> to go to the previous window. You can destroy (kill) the current window with <strong>C-a k</strong>.</p>
<h3>Copying and pasting text</h3>
<p>The screen tool also enables you to copy any text on the screen and paste it later wherever you can type some text.</p>
<p>The <strong>C-a [</strong> keybinding frees your cursor of any constraints and lets it go anywhere your will takes it using the arrow keys on your keyboard. To select and copy text, move to the start of the string you want to copy, and press <strong>Enter</strong> on the keyboard. Then move the cursor to the end of the text you want to copy and press <strong>Enter</strong> again.</p>
<p>After you’ve done that, use <strong>C-a ]</strong> to paste that text in your shell. Or you can open a text editor like <em>vim</em> or <em>nano</em> and paste the text you copied there.</p>
<h2>Important notes about screen</h2>
<p>Here are some other tips to keep in mind when using this utility.</p>
<h3>Privileged sessions vs. sudo inside a screen</h3>
<p>What if you need to run a command with root privileges inside screen? You can run either of these commands:</p>
<pre class="wp-block-preformatted">$ screen -S sessionname sudo command
$ sudo screen -S sessionname command</pre>
<p>Notice that the second command is like running this command:</p>
<pre class="wp-block-preformatted"># screen -S sessionname command</pre>
<p>Seeing things this way makes it a lot more obvious coupled with the fact that each screen is associated to a user:</p>
<ul>
<li>The first one creates a screen with root privileges that can be accessed by the current user even if, within that screen, they switch to another user or <em>root</em> using the <em>sudo -i</em> command.</li>
<li>The second one creates a screen that can only be accessed by the <em>root</em> user, or by running <em>sudo screen -r</em> as a user with the <a href="https://fedoramagazine.org/howto-use-sudo/">appropriate <em>sudo</em> access</a>.</li>
</ul>
<h3>Notes about screen in systemd units</h3>
<p>You might be tempted to run a screen session in the background as part of a systemd unit executed at startup, just like any Unix daemon. That way you can resume the screen session and interact with whatever you ran that way. That can work, but you need to consider that it requires the right setup.</p>
<p>By default, <a href="https://www.freedesktop.org/software/systemd/man/systemd.service.html">systemd assumes</a> services are either <em>oneshot,</em> meaning they set up something and then shut down, or <em>simple</em>. A service is simple by default when you create a unit file with no <em>Type</em>. What you actually need to do is to set the <em>Type</em> to <em>forking</em>, which describes <em>screen</em>‘s actual behavior when the <strong>-dm</strong> option is passed. It starts the process and then forks itself, leaving the process running in the background while the foreground process closes.</p>
<p>If you don’t set that, that <em>screen</em> behavior is interpreted by systemd as the service exiting or failing. This causes systemd to kill the background process when the foreground process exits, which is not what you want.</p>
<hr class="wp-block-separator" />
<p><em>Photo by <a href="https://unsplash.com/@tchompalov?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Vlad Tchompalov</a> on <a href="https://unsplash.com/s/photos/screen?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>.</em></p>
</div>
https://www.sickgaming.net/blog/2019/12/...th-screen/
<div><p>When you manage a Linux instance, you’ll find that your job is made much easier by the many tools designed specifically to deal with something specific within the system. For example, if you need to install packages, you have easy-to-use package managers that make that a breeze. If you need to create, resize or delete filesystems, you can do so using tools that are built to be used by humans. The same goes for managing services and browsing logs with <a href="https://fedoramagazine.org/what-is-an-init-system/">systemd</a> using the <em>systemctl</em> and <em>journalctl</em> commands respectively. The <em>screen</em> tool is another such example.</p>
<p>You can run all of those tools directly at the command line interface. But if you’re connecting to a server remotely using SSH, sometimes you need another layer between you and the operating system so the command you’re running doesn’t stop if your remote connection terminates. Sysadmins do this to prevent sudden termination in case of a connection issue, but also on purpose to run a command that needs to keep running indefinitely in the background. Enter the <em>screen</em> utility.</p>
<p> <span id="more-29819"></span> </p>
<h2>Introducing screen</h2>
<p>The <em>screen</em> tool allows you to have multiple sessions (called <em>screens</em>) that are independent from each other and that you can name, leave and join as you desire. It’s multi-tasking for the remote CLI. You can get started with it simply by running this command:</p>
<pre class="wp-block-preformatted">$ screen</pre>
<p>The command creates a screen and connect you to it: your current session is now a screen. You can run any command that does something and doesn’t automatically terminate after a few seconds. For example, you might call a web app executable or a game server. Then press <strong>Ctrl+A</strong> and, right after that, the <strong>D</strong> key and you will <em>detach</em> from the screen, leaving it running in the background.</p>
<p>The <strong>Ctrl+A</strong> combination, given that it is part of every <em>screen</em> command, is often shortened in documentation to <strong>C-a</strong>. Then the <em>detach</em> command used earlier can be described simply as <strong>C-a d</strong>. </p>
<h3>Getting in and out of sessions</h3>
<p>If you want to connect to that screen again, run <em>screen -r</em> and you will <em>attach</em> to that screen. Just running <strong>screen</strong> will create a new screen, and subsequent <em>screen -r</em> commands will print out something like this:</p>
<pre class="wp-block-preformatted">There are several suitable screens on: 5589.pts-0.hostname (Detached) 5536.pts-0.hostname (Detached) Type "screen [-d] -r [pid.]tty.host" to resume one of them.</pre>
<p>You can then choose whether to resume the first or the second screen you created by running either one of these commands:</p>
<pre class="wp-block-preformatted">$ screen -r 5536
$ screen -r 5589</pre>
<p>Adding the rest of the name of the string is optional in this case.</p>
<h3>Named screens</h3>
<p>If you know you’ll have multiple screens, you might want to be able to connect to a screen using a name you choose. This is easier than choosing from a list of numbers that only reflect the process IDs of the screen sessions. To do that, use the <em>-S</em> option as in the following example:</p>
<pre class="wp-block-preformatted">$ screen -S mywebapp</pre>
<p>Then you can resume that screen in the future using this command:</p>
<pre class="wp-block-preformatted">$ screen -r mywebapp</pre>
<h3>Starting a process in the background using screen</h3>
<p>An optional argument is the command to be executed inside the created session. For example:</p>
<pre class="wp-block-preformatted">$ screen -S session_name command args</pre>
<p>This would be the same as running:</p>
<pre class="wp-block-preformatted">$ screen -S session_name</pre>
<p>…And then running this command inside the <em>screen</em> session:</p>
<pre class="wp-block-preformatted">$ command args</pre>
<p>The screen session will terminate when the command finishes its execution.</p>
<p>This is made particularly useful by passing the <strong>-dm</strong> option, which starts the screen in the background without attaching to it. For example, you can copy a very large file in the background by running this command:</p>
<pre class="wp-block-preformatted">$ screen -S copy -d -m cp /path/to/file /path/to/output</pre>
<h2>Other screen features</h2>
<p>Now that you’ve seen the basics, let’s see some of the other most commonly used screen features.</p>
<h3>Easily switching between windows in a screen</h3>
<p>When inside a screen, you can create a new window using <strong>C-a c</strong>. After you do that, you can switch between the windows using <strong>C-a n</strong> to go to the next one and <strong>C-a p</strong> to go to the previous window. You can destroy (kill) the current window with <strong>C-a k</strong>.</p>
<h3>Copying and pasting text</h3>
<p>The screen tool also enables you to copy any text on the screen and paste it later wherever you can type some text.</p>
<p>The <strong>C-a [</strong> keybinding frees your cursor of any constraints and lets it go anywhere your will takes it using the arrow keys on your keyboard. To select and copy text, move to the start of the string you want to copy, and press <strong>Enter</strong> on the keyboard. Then move the cursor to the end of the text you want to copy and press <strong>Enter</strong> again.</p>
<p>After you’ve done that, use <strong>C-a ]</strong> to paste that text in your shell. Or you can open a text editor like <em>vim</em> or <em>nano</em> and paste the text you copied there.</p>
<h2>Important notes about screen</h2>
<p>Here are some other tips to keep in mind when using this utility.</p>
<h3>Privileged sessions vs. sudo inside a screen</h3>
<p>What if you need to run a command with root privileges inside screen? You can run either of these commands:</p>
<pre class="wp-block-preformatted">$ screen -S sessionname sudo command
$ sudo screen -S sessionname command</pre>
<p>Notice that the second command is like running this command:</p>
<pre class="wp-block-preformatted"># screen -S sessionname command</pre>
<p>Seeing things this way makes it a lot more obvious coupled with the fact that each screen is associated to a user:</p>
<ul>
<li>The first one creates a screen with root privileges that can be accessed by the current user even if, within that screen, they switch to another user or <em>root</em> using the <em>sudo -i</em> command.</li>
<li>The second one creates a screen that can only be accessed by the <em>root</em> user, or by running <em>sudo screen -r</em> as a user with the <a href="https://fedoramagazine.org/howto-use-sudo/">appropriate <em>sudo</em> access</a>.</li>
</ul>
<h3>Notes about screen in systemd units</h3>
<p>You might be tempted to run a screen session in the background as part of a systemd unit executed at startup, just like any Unix daemon. That way you can resume the screen session and interact with whatever you ran that way. That can work, but you need to consider that it requires the right setup.</p>
<p>By default, <a href="https://www.freedesktop.org/software/systemd/man/systemd.service.html">systemd assumes</a> services are either <em>oneshot,</em> meaning they set up something and then shut down, or <em>simple</em>. A service is simple by default when you create a unit file with no <em>Type</em>. What you actually need to do is to set the <em>Type</em> to <em>forking</em>, which describes <em>screen</em>‘s actual behavior when the <strong>-dm</strong> option is passed. It starts the process and then forks itself, leaving the process running in the background while the foreground process closes.</p>
<p>If you don’t set that, that <em>screen</em> behavior is interpreted by systemd as the service exiting or failing. This causes systemd to kill the background process when the foreground process exits, which is not what you want.</p>
<hr class="wp-block-separator" />
<p><em>Photo by <a href="https://unsplash.com/@tchompalov?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Vlad Tchompalov</a> on <a href="https://unsplash.com/s/photos/screen?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>.</em></p>
</div>
https://www.sickgaming.net/blog/2019/12/...th-screen/