Browse Prior Art Database

Job Migration between Terminals Disclosure Number: IPCOM000171070D
Original Publication Date: 2008-May-28
Included in the Prior Art Database: 2008-May-28
Document File: 2 page(s) / 105K

Publishing Venue



In Unix with job control, a whole session is killed by SIGHUP when terminal driver detects connection failure. But sometimes we want to keep job running even after a connection failure is detected. Screen, nohup, VNC and daemon are some existing solutions. Their drawback is that they should be applied before/when starting a job. The core idea of our invention is to migrate Unix job between two different terminals in the same node when the job is still running. From the perspective of process relationship, the job is moved from one session to another. By moving the job control to the target session/terminal, the job keeps running even if the source terminal is disconnected. The advantages of this solution comparing with the existing ones are: 1. Can be applied when the job is running 2. Can benefit from the migration of process relationship, e.g. An user applies an account for a period of time and pays for it. He logins the system with the account and launches his job. The strategy is to kill his job launched with this account. But actually the job runs more time than expected. Fortunately, there is another account available to him, so he migrates the job to another account. The process subtree of the previous login session is killed when time is out, but since the job has been moved to another subtree, it's not affected. For the prior arts, since the process relationship is not changed when they are running, they don't have such benefit. 3. Protect sensitive output: e.g. sometimes we want a person to get the output of job from his console but don't expect other persons to do that. We may migrate the job to his console but don't do that for other persons. But for the prior arts, they are unique, i.e. any person who has the access authority can access the output in Screen or VNC. 4. Can provide interactive operation comparing with nohup and daemon

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Job Migration between Terminals

Figure 1 shows the work flow of job migration. It can be divided into three stages: preparation, body and finalization.

1. Preparation: In this stage,

job migration is kicked off and a communication channel is established between the source and the target shells, and then both

shells/sessions negotiate job migration. Authorization or security check is performed in the negotiation. After the handshake, the job is stopped so there is no further execution and interaction with the terminalin the job. The procedure to kickoff job migrationdepends on implementation. Here is an example by providing a build-in shell command.

Say mgrt is a new build-in shell command. Command line "mgrt -s <


" is to send a migration request, and "mgrt -a

" to accept the

request. Say we want to migrate job1 from shell1/term1 to shell2/term2. First, issue "mgrt -s job1 shell2/term2" on term1. It opens and listens on a socket/named pipe/etc. and send a request to term2 by wall or something else like that. Then, accept the migration request by issuing "mgrt -a socket/named pipe" on term2. After that, a communication channelis established between the source and the target shells with the socket/named pipe/etc. At last, bothof them can start to negotiate migration and exchange information via the channel.

2. Body: In this stage, a request is sent to the kernel for job migration. The kernel detaches all theprocesses in the job fr...