Next Steps

[mkohlmyr]

Feature list

Current

• scrum start session
• scrum start session window
• scrum open session
• scrum kill session

Desired

• A scrum daemon. Keep track of all scrum sessions that have been started. Keep track of their windows. Protocol? UNIX socket?
• scrum open session window
• scrum kill session window
• scrum status
• scrum status session
• scrum status session window

  Misc todo

• Do not open extra bash window (or rather close it once other windows are open)
• Rename kill to end or stop? (note to self, kill should alias stop, don't break the API)
• Shorthand window names? Mapped to full name, e.g. scrum start node-services am. This allows the full name to be the title, but for us to know it by another name when executing commands. Essentially turning the window title into more of a descriptive header.
• Building on shorthand: include pid in title.
• Record and keep track of window number for each started window so that it can be used for commands in place of window name? This works hand in hand with shorthand.

  Moonshot

• Would it be possible to do individual ssh's in different windows (similar to cwd) and thus end up with a serssion showing terminals from not just separate processes but separate servers? That would be very neat.
• A way to chroot sessions and / or windows
• Some kind of integration (or instructions for working) with a deployment system / strategy

[mkohlmyr]

• keep track of pids of screen windows. would require some ptn.stdout magic?
  • instead of directly executing things, we should possibly run it through a bash script so that we can execute and write pid to a file.
  • kill initial bash window if other windows are defined and started. if the above, then explicitly start bash and just kill the pid.
  • read and print stderr when starting windows?

an option for stderr is redirecting it with the bash script into an error output file and printing that

[mkohlmyr]

for open, allow selecting a window using -p "preselect the named window if it exists

[mkohlmyr]

in terms of killing the initial bash,we could simply target window Num 0 with kill -9 $$

so we send a command over -X and use -p to target the window by number or name.

[mkohlmyr]

in terms of tracking pids, we can simply use $$ in the started shell prior to running "execs" and do with it as we wish

[mkohlmyr]

negative pid to kill = pgip (pid group)

[mkohlmyr]

also worth writing down explicitly: separate specified cwd from execs. only thing in execs should be the eventual pid, and as such the field should possibly be renamed.

[mkohlmyr]

also consider moving to sessions being an array of objects with a name field rather than an object of kvps s.t. name -> obj

[mkohlmyr]

also allow specifying an overarching cwd for the session?

[mkohlmyr]

checking pid status: $ kill -0 $PID no output if the process exists, else bash: kill: ($PID) - No such process alt.

$ kill -0 1 || true
bash: kill: (1) - Operation not permitted
$ kill -0 123123123 || true
bash: kill: (123123123) - No such process
$ kill -0 6378 || true

or

$ ps -p 6378
  PID TTY          TIME CMD
 6378 pts/28   00:00:00 sh
$ ps -p 6378123
  PID TTY          TIME CMD

or optionally

$ ls -l /proc/6379
total 0
...
lrwxrwxrwx  1 mikaelk mikaelk 0 Jul 22 10:49 cwd -> /home/mikaelk/dev/.../node/...
lrwxrwxrwx  1 mikaelk mikaelk 0 Jul 22 10:35 exe -> /usr/bin/nodejs
...

$ ls -l /proc/6378
total 0
...
lrwxrwxrwx 1 mikaelk mikaelk 0 Jul 22 10:52 cwd -> /home/mikaelk/dev/.../node/...
lrwxrwxrwx 1 mikaelk mikaelk 0 Jul 22 10:52 exe -> /bin/dash
...

Note that time is the cumulated cpu time.

Also worth seeing:

$ ps -ejH
 6339  6339  6339 ?        00:00:00         screen
 6340  6340  6340 pts/14   00:00:00           bash
 6345  6345  6345 pts/23   00:00:00           sh
 6349  6345  6345 pts/23   00:00:04             node
 6352  6352  6352 pts/24   00:00:00           sh
 6354  6352  6352 pts/24   00:00:03             node
 6359  6359  6359 pts/25   00:00:00           sh
 6364  6359  6359 pts/25   00:00:11             node
 6360  6360  6360 pts/26   00:00:00           sh
 6361  6360  6360 pts/26   00:00:07             node
 6368  6368  6368 pts/27   00:00:00           sh
 6369  6368  6368 pts/27   00:00:03             node
 6378  6378  6378 pts/28   00:00:00           sh
 6379  6378  6378 pts/28   00:00:09             node

[mkohlmyr]

$ ps -eo pid,sid,stat
 6339  6339 Ss
 6340  6340 Ss+
 6345  6345 Ss+
 6349  6345 Sl+
 6352  6352 Ss+
 6354  6352 Sl+
 6359  6359 Ss+
 6360  6360 Ss+
 6361  6360 Sl+
 6364  6359 Sl+
 6368  6368 Ss+
 6369  6368 Sl+
 6378  6378 Ss+
 6379  6378 Sl+

S = sleep, waiting s = session leader as evidenced by sid (pgid is same for these processes but not in general. pgrp = pgid) l = multi threaded

• = is in foreground of process group (essentially the shell and the visible process) http://www.linuxquestions.org/questions/linux-general-1/ps-stat-fields-563716/

also note ppid field which lists the parent pid explicitly.

using these means we could almost certainly figure out which node processes relate to which shells / screen windows

we can then also use top in batch mode to get information about cpu and memory usage

$ top -b -d 0 -n 1 >>top-file
# -b       batch mode
# -d 0     delay 0 seconds
# -n 1     write once
$ cat top-file
op - 11:35:13 up  1:08,  3 users,  load average: 1.14, 1.41, 1.38
Tasks: 306 total,   2 running, 299 sleeping,   5 stopped,   0 zombie
%Cpu(s):  4.5 us,  2.9 sy,  0.1 ni, 92.2 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:   6109312 total,  5987656 used,   121656 free,   471760 buffers
KiB Swap:  2094076 total,      584 used,  2093492 free.  1619820 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
...
 6339 mikaelk   20   0   29040   3332    868 S   0.0  0.1   0:00.54 screen
 6340 mikaelk   20   0   23576   4628   1672 S   0.0  0.1   0:00.05 bash
 6345 mikaelk   20   0    4444    660    552 S   0.0  0.0   0:00.00 sh
 6349 mikaelk   20   0 1100012  68844   7316 S   0.0  1.1   0:05.68 node
 6352 mikaelk   20   0    4444    656    552 S   0.0  0.0   0:00.00 sh
 6354 mikaelk   20   0 1075576  41812   6548 S   0.0  0.7   0:05.16 node
 6359 mikaelk   20   0    4444    660    552 S   0.0  0.0   0:00.00 sh
 6360 mikaelk   20   0    4444    660    552 S   0.0  0.0   0:00.00 sh
 6361 mikaelk   20   0 1077920  58452   6556 S   0.0  1.0   0:11.60 node
 6364 mikaelk   20   0 1083580  66600   6552 S   0.0  1.1   0:17.59 node
 6368 mikaelk   20   0    4444    656    552 S   0.0  0.0   0:00.00 sh
 6369 mikaelk   20   0 1075516  41476   6576 S   0.0  0.7   0:04.82 node
 6378 mikaelk   20   0    4444    656    552 S   0.0  0.0   0:00.00 sh
 6379 mikaelk   20   0 1077920  44160   6536 S   0.0  0.7   0:13.70 node
...

There may also be use cases for wait $PID which executes things after the pid dies. E.g. waiting for session leader which will exit when its node process does.

[mkohlmyr]

field on the right is ppid, note that it now matches what we see in the tree view

$ ps -eo pid,sid,pgid,pgrp,ppid
...
 6339  6339  6339  6339  2129
 6340  6340  6340  6340  6339
 6345  6345  6345  6345  6339
 6349  6345  6345  6345  6345
 6352  6352  6352  6352  6339
 6354  6352  6352  6352  6352
 6359  6359  6359  6359  6339
 6360  6360  6360  6360  6339
 6361  6360  6360  6360  6360
 6364  6359  6359  6359  6359
 6368  6368  6368  6368  6339
 6369  6368  6368  6368  6368
 6378  6378  6378  6378  6339
 6379  6378  6378  6378  6378
...

[mkohlmyr]

[moved to op]

[mkohlmyr]

regarding ssh support $ ssh -t xxx.xxx.xxx.xxx "cd /directory_wanted ; bash" or $ ssh -t xxx.xxx.xxx.xxx "cd /directory_wanted && exec \$SHELL" -> shell in directory_wanted

however we want non interactive password authentication. sshpass unfortunately not included by default, would have to be an explicit dependency $ sshpass -p 't@uyM59bQ' ssh username@server.example.com .. $ sshpass -pfoobar ssh -o StrictHostKeyChecking=no user@host command_to_run - hostkeychecking means first time connecting you are asked to validate the host interactively .. dont want this.

The really interesting part will then be getting input into the ssh shell in order to start the program. I wonder if ptn.stdin.write will simply work?

Also worth taking a lot of care in deciding on the semantics of scrum kill session and scrum kill session window. If they should actually should kill the process inside ssh not the ssh shell, this could be problematic. If ptn can listen to signals that might be useful.

[mkohlmyr]

in the first bash shell, prior to quitting:

echo '{"cmd": "started", "data": {...}}' | nc -U "/tmp/scrumd.sock"

where data should hold the screen pid:

ps -p $$ -o ppid=

and then exit the shell.. perhaps started should be session instead, as in it is identifying a session for us.

this is perhaps best done via a bash script executing?

[mkohlmyr]

unix socket server for testing:

    server = net.createServer (sock) ->
        sock.on "data", (packet) ->
            packet = JSON.parse packet
            {{COMMAND DISPATCH MAP}}[packet.cmd] packet.data, sock
            console.log packet
        return
    server.listen "/tmp/scrumd.sock"

[mkohlmyr]

take a look at the tree structure when running both python and node to be sure of hunch as far as 1x screen per session!

[mkohlmyr]

pid=`echo $$`
ppid=`ps -p $$ -o ppid= | tr -d ' '`
echo "{\"cmd\": \"started\", \"data\": {\"pid\": \"$pid\", \"ppid\": \"$ppid\"}}" | nc -U "/tmp/scrumd.sock"

net = require "net"

server = net.createServer (sock) ->
    sock.on "data", (packet) ->
        console.log JSON.parse packet
    return
server.listen "/tmp/scrumd.sock"

[mkohlmyr]

actuall ythe script will get the pid of itself and ppid of the shell, not screen. we should pass $$ as the argument to the bash script file instead.

ppid=`ps -p $1 -o ppid= | tr -d ' '`
echo "{\"cmd\": \"started\", \"data\": {\"pid\": \"$1\", \"ppid\": \"$ppid\"}}" | nc -U "/tmp/scrumd.sock"

[mkohlmyr]

ptn.stdin.write "screen -S #{name} -p 0 -X stuff \"ls\n\"\n"

[mkohlmyr]

ptn.stdin.write "screen -S #{name} -p 0 -X stuff \"sh #{shellscript} $$\n\"\n" got pid not ppid

[mkohlmyr]

it stuffs with $$ already evaluated, probably to a temporary process (stuff) which then dies and so even ps -p 19170 comes up empty.

need to stuff literal $$

[mkohlmyr]

working but sending extra newline to daemon?

[mkohlmyr]

example seen on the web, potentially useful for scrum open?

screen -ls | grep main && urxvt -name screen -e screen -x main || urxvt -name screen -e screen -R -S main
# Start urxvt and do whatever is needed to open the screen session named "main"
# Open a terminal (urxvt in this case) to connect to a screen session (named "main") 
# and create the screen session if necessary.

[mkohlmyr]

Note potentially useful pidof command

[mkohlmyr]

Implementing a status bar (particularly assuming we can run screen with a provided .screenrc, perhaps combined with the default / overwriting the default / being overwritten by the default)

If you don't have a hardstatus line, you have two choices. 
The first is to use the command hardstatus lastline, which tells screen to 
reserve the last line of the display for use as a hardstatus line. 
With a hardstatus string param command, you will get a status bar 
at the bottom of your display.

The second option is to use the caption command. When the 
display is split into multiple regions [...], screen puts a caption 
at the bottom of each region. You can use the caption always 
command to always display the caption, even if the display is not split

Just as with hardstatus, there's a caption string param command that 
can be used to make a status bar. It uses all the same string escapes 
that the hardstatus command does.

http://www.kilobitspersecond.com/2014/02/10/understanding-gnu-screens-hardstatus-strings/