ETA in --status is showed using offset from current time, not from the moment session file was written

[AlekseyCherepanov]

Minor problem

I run a long session. In parallel, I print its status using --status. I get ETA based on current time, i.e. ETA grows when I rerun --status after a few seconds.

So I get up to 1 minute (Save = 60) discrepancy with actual ETA for running session.

For a stopped session, ETA in --status would mean ETA if I start right now.

[solardiz]

Maybe --status shouldn't print ETA at all? Maybe it currently printing ETA is inadvertent?

[AlekseyCherepanov]

Also percents of progress are rounded in report by --status.

$ john pw-fake-md5 --format=raw-md5 --mask='?d?d?d?d?d?d?d?d?d?d'

Attempt at getting close stats from session file and from terminal:

$ (inotifywait JohnTheRipper/run/john.rec && john --status) & killall -HUP john && killall -USR1 john; sleep 1
[1] 27156
Setting up watches.
Watches established.
JohnTheRipper/run/john.rec MODIFY 
0g 0:00:07:13 96,00% (ETA: 16:24:23) 0g/s 22325Kp/s 22325Kc/s 22325KC/s
[1]+  Done [...]

Main john's stdout:

0g 0:00:07:12 96,67% (ETA: 16:24:19) 0g/s 22377Kp/s 22377Kc/s 22377KC/s 1572314557..0803314557

[magnumripper]

The status file is only updated once a minute or so, and depending on mode it may not even be able to resume to that exact point. So of course it lags from the running session.

I see no problem with any of this but I wouldn't reject to dropping ETA from --session output either.

[magnumripper]

I'm marking as invalid but don't let that discourage you, we can discuss it further.

[AlekseyCherepanov]

Having stable speed, ETA would be the same for running session no matter when the session file was written. With current implementation, ETA grows. But current discrepancy is limited to 1 minute, also discrepancy happens due to small speed changes anyway.

I don't think dropping ETA is good. ETA is a cool feature and some workflows rely on --status: some users prefer to dispatch john sessions into background without output and check progress using --status, i.e. they don't have an attached terminal at all to see status lines as usual.

[magnumripper]

Having stable speed, ETA would be the same for running session no matter when the session file was written.

How? Since we don't actually store the ETA but the progress, the --status output for a 15 second old file will calculate an ETA 15 seconds later than the still running session. One could say the --status option assumes we're checking a paused session and ETA is shown as "if we resumed right now".

If we stored the actual ETA string 16:24:23 in the session file, we could achieve what you ask for, but that would be extremely confusing if job isn't actually running.

[AlekseyCherepanov]

We may distinguish running and stopped session checking lock on .rec file.

Theoretically, for running session, we may use mtime of session file as the base or store time into session file (either time of writing, or ETA).

And for stopped session, it may be useful to tell user that ETA would be so if we resume right now.

[magnumripper]

True, and not too complicated. Pretty good ideas actually. Would you have time to implement it?

Some borken systems don't have locks though. For those, we could assume that an mtime newer than 2 * timer_save_interval seconds means job is running, but it will sometimes get a false negative.

[AlekseyCherepanov]

I will not have time to implement it.

I heard mtime is not very good idea, because there are network file systems. man nfs tells that default max caching of attributes of regular file is 60 seconds. Also FAT file system is well-known to have 2 second time precision.

Hm, I don't know how locks play with network file systems.

[AlekseyCherepanov]

we could assume that an mtime newer than 2 * timer_save_interval seconds means job is running, but it will sometimes get a false negative.

For example, john.conf might be changed and newer invocations will use smaller value for Save option, i.e. we cannot know timer_save_interval reliably.