[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <099af1f432410eed9aebf08590259e44@smtp.hushmail.com>
Date: Fri, 20 Nov 2020 15:20:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Session management on AMI - Interrupting and
resuming
On 2020-11-20 14:01, SQP Admin wrote:
> 1. Is the approach we’ve taken to take advantage of the 96 CPUs correct?
> (—fork=96) - or is there a better way of leveraging that instance
> performance?
Did you try benchmarking using OpenMP instead? That's normally better
for slow formats like ZIP, even if benchmark speeds might be a tad
slower (many other aspects weigh in).
> 2. We had to logout from our ssh session a couple of times and don’t
> know how to reconnect to our John session. We understand using
> —status=[sessionname] prints a status of the relevant session, however
> is there a way to reconnect to the session as when it was launched the
> first time and when pressing any key would display the status?
Kill it and resume it, see below.
> 3. As we are not connected to the John session anymore, we are unable to
> figure out how to interrupt it gracefully, as we would usually do using
> “q” when connected to a live session. Could you please advise on how to
> interrupt sessions after reconnecting to the instance’s ssh?
You should use "screen" or the like, for not getting in this situation.
Once running (and understanding) screen, kill the running session simply
using "kill <pid>". Then resume it with eg. "./john -restore=<name>" and
you should be back on track.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
