46
edits
QA/Execution/Web Testing/Automation/Screen Tutorial: Difference between revisions
Jump to navigation
Jump to search
QA/Execution/Web Testing/Automation/Screen Tutorial (view source)
Revision as of 23:26, 17 February 2011
, 17 February 2011no edit summary
No edit summary |
|||
| Line 33: | Line 33: | ||
We will be running all of the processes on the OSX machines in screen sessions now. This means that all RCs (with the exception of Windows VM RCs), the Grid Hub, and the Hudson server will all be run via screen. In practice, this is not much different than we do it now - instead of having many tabs with each process being in its own tab, we will now have multiple screen sessions. Depending on feedback, we can keep the tabs open on the machines themselves (with each tab reattached to a screen session), or we don't. Leaving the screen sessions in tabs is beneficial because users of the physical machine (and VNC) can see the console output without having to worry about screen. However, not having these tabs open (and thus letting the user reattach the screen session they want when they want), we maintain a cleaner desktop with fewer visible programs running. | We will be running all of the processes on the OSX machines in screen sessions now. This means that all RCs (with the exception of Windows VM RCs), the Grid Hub, and the Hudson server will all be run via screen. In practice, this is not much different than we do it now - instead of having many tabs with each process being in its own tab, we will now have multiple screen sessions. Depending on feedback, we can keep the tabs open on the machines themselves (with each tab reattached to a screen session), or we don't. Leaving the screen sessions in tabs is beneficial because users of the physical machine (and VNC) can see the console output without having to worry about screen. However, not having these tabs open (and thus letting the user reattach the screen session they want when they want), we maintain a cleaner desktop with fewer visible programs running. | ||
=== | === How to Use Screen (Step By Step) === | ||
Right now, you probably are already aware how to connect to the QASel machines via VPN and VNC. (If you don't, basically you connect to MV-Office VPN and then VNC into qa-selenium.mv.mozilla.com or whichever machine you want). Keep in mind that if you want to interact with the actual OSX desktop, you still need to use VNC. | |||
However, if you want to simply view, start, or stop one of the Terminal processes (i.e. RCs, Grid Hub, Hudson), then you have the option of using screen! | |||
To do this, the first thing you want to do is start an SSH session. This can be done with your favorite SSH client (Putty for Windows) or a simple ssh command in Terminal (OSX/Linux - type "ssh webqa@qa-selenium.mv.mozilla.com" and enter password). Once SSH'd into whichever box, you will be greeted with a blank shell, as if you just opened a new Terminal. | |||
If you want to simply view what may already be running (say if somebody else started RCs, etc), type "screen -ls" in the SSH window. This will print out a list of all the active screen sessions (think of them as the various tabs that you would see if you were to VNC into the machine). Now, to reattach to a specific screen session (analogous to clicking on the tab to bring it to the foreground and gain focus), you simply type "screen -r <session name>". The session name is what was displayed when you did the -ls. Once you do that, your terminal window will change to as if you had just switched tabs (so you'll see the process running, etc). You can interact with it as if you were working directly on the terminal window (so control+c to interrupt, restart by running whatever commands, etc). | |||
If you want to start a NEW screen session (particularly so that you can start a new RC, or after a fresh hard machine restart), then you type "screen -S <session name>". This tells the terminal that you want a new screen session (the same can be achieved by typing simply "screen", and the -S <screen session> allows you to name it so that you can tell what it is when you run a "screen -ls" command. If you leave out the -S flag, then the default name will be some number (process ID, maybe?) and identifying what that corresponds to without reattaching the screen is annoying. (Note that you will still see the number even if you use the -S flag when you -ls, and that you can reattach (see above) using either the session name OR the number. | |||
Now, since you are inside of a screen session, the screen session is capturing all of your commands and keystrokes (including things like ctrl+c interrupt and ctrl+d exit) - it will be sent to your screen session. In order to send a command to a screen session, you need to first press ctrl+a. This will signify that the next button you press is meant for the screen PROCESS and not for whatever it is running within it. For example, to detach from a screen session (so that you return back to the terminal you were at before you typed "screen" while leaving anything that is occurring on this screen session running in the background), you do ctrl+a, release that, and then press d. You'll see a notification with "detached from screen <name>". It is strongly advised that you always detach from a screen when you are done viewing it and before you disconnect from SSH, especially if you want it to persist after you log out. Another command that can be sent is the kill command. This is done with ctrl+a, and then k. It will request [y/n] confirmation and immediately terminate the screen session you are working on (so that any process within it is stopped, and it no longer shows up in -ls). | |||
You can have as many screen sessions running as you'd like, but try to remember to detach/kill the screen session you're currently within before trying to start a new one with "screen". This way, all of them will show up when -ls is run from the primary terminal. | |||