[slurm-dev] funky input handling with sattach
Dan Bassett
We're attempting to use SLURM 2.1.9 here to launch instances of User
Mode Linux on a small cluster of machines, and then later connect to
them using sattach. The ultimate goal is to have students be able to
launch their own UML machine and connect to it. Part of the course
requires that the student configure the network interface(s) in their
machine and build an SSH daemon, so sattach is ideal because it allows
users to connect to their machine without requiring it to be connected
to the network. Of course, I might just have a bit of hammer syndrome
here, because my last job was as an HPC admin and I used SLURM
extensively there :-)
Anyway, on to the problem...
When I start up a UML instance thusly:
srun -n 1 --pty /home/dbassett/linux-2.6.24-x86_64
ubda=CentOS5-AMD64-root_fs mem=128M
It runs just fine, and I can interact with it in that terminal
normally. However, when I sattach to it in another terminal, I start to
get some odd behavior. When I type in a command and hit return,
whatever I typed is echoed back at me and then the output of the command
gets printed out, for example:
[root@localhost ~]# date
date
Wed Jun 16 11:45:41 EDT 2010
Over in the original terminal where I launched UML with srun, I see the
expected output:
[root@localhost ~]# date
Wed Jun 16 11:45:41 EDT 2010
Another point of data is that when I'm running "top", hitting "q" in the
original terminal causes it to exit as expected. However, over in the
second terminal with sattach running, hitting "q" by itself does
nothing. I instead must hit "q" followed by "enter" in order to make it
quit. If I hit "q" in the sattach session, and then quit "top" in the
srun terminal, and then go back to the sattach terminal and hit enter, I
get "q: command not found", so it would appear that the "q" is staying
in a buffer somewhere.
I'm absolutely stumped here...any help would be appreciated :-)
Dan
P.S. I obtained the kernel and filesystem from the following places for
testing purposes...we'll build our own when we decide to move forward:
http://**user-mode-linux.sourceforge.net/linux-2.6.24-x86_64.bz2
http://**fs.devloop.org.uk/filesystems/CentOS-5/CentOS5-AMD64-root_fs.bz2
Mark A. Grondona
Unfortunately, I'm not sure that --pty and sattach will play very
well together. At the very least, sattach will have to put its
stdin into raw mode (and I don't think sattach supports an option
to do this at this time).
It probably could be done with a bit of testing and some patches for
sattach. However, attaching and reattaching to ptys is what screen
and tmux do really well. I wonder if one of these could be integrated
with SLURM to do what you want?
mark
Dan Bassett
(haven't used it previously, though) do what we're after. However,
using a utility that's already integrated with SLURM that's intended to
connect to and interact with processes seems to be a much more elegant
(and less kludgey) solution. Unless of course there's some technical
reason beyond my understanding why sattach has had this functionality
omitted.
Dan
>> http://***user-mode-linux.sourceforge.net/linux-2.6.24-x86_64.bz2
>> http://***fs.devloop.org.uk/filesystems/CentOS-5/CentOS5-AMD64-root_fs.bz2
>>
>>
>>
jet...@llnl.gov
It just a matter of priorities.
Mark A. Grondona
> I'm sure something could be scripted up to make screen or even tmux
> (haven't used it previously, though) do what we're after. However,
> using a utility that's already integrated with SLURM that's intended to
> connect to and interact with processes seems to be a much more elegant
> (and less kludgey) solution. Unless of course there's some technical
> reason beyond my understanding why sattach has had this functionality
> omitted.
>
> Dan
Well, there are a lot of tricky things that GNU screen and similar programs
handle already that would be difficult to do in SLURM. However, like
I said it would probably just take some minor changes in sattach to
handle the basic case of reattaching to a pty, it might even be
enough to place the tty of sattach into raw mode. The question then
is what to do with the terminal size and resize events. I'm not even
sure what would be the best way to handle that in SLURM.
I mention screen & friends only because it is a solution that should
fully work now, is very well tested, and will have a lot more flexibilty
than a tty multiplexing solution implemented in native SLURM utilities.
That being said, my opinion is that it is a good idea to support a
rudimentary --pty in sattach.
mark
> >> http://***user-mode-linux.sourceforge.net/linux-2.6.24-x86_64.bz2
> >> http://***fs.devloop.org.uk/filesystems/CentOS-5/CentOS5-AMD64-root_fs.bz2
> >>
> >>
> >>
>
>