If hasher kills all lingering processes after the main process exit, some data may be lost.
If hasher doesn't kill all lingering processes after the main process exit, the wait may take too long.
Somebody is going to be unhappy whatever approach is chosen.
Maybe you want an option.

I suggest user confirmation - kill (y/n) or wait longer.

Also, what data could be lost in the hasher?

(In reply to Vitaly Chikunov from comment #2)
> I suggest user confirmation - kill (y/n) or wait longer.

Snatch terminal from remaining hasher processes?

> Also, what data could be lost in the hasher?

Any kind of data processed inside hasher.

For example, if the main process fails to wait for its child processes properly,
the killing spree would terminate these processes prematurely.

(Ответ для Dmitry V. Levin на комментарий #3)
> (In reply to Vitaly Chikunov from comment #2)
> > I suggest user confirmation - kill (y/n) or wait longer.
> 
> Snatch terminal from remaining hasher processes?

Design is such that user cannot be asked?

> > Also, what data could be lost in the hasher?
> 
> Any kind of data processed inside hasher.
> 
> For example, if the main process fails to wait for its child processes
> properly,
> the killing spree would terminate these processes prematurely.

Thanks. But, how would you resolve this situation otherwise? (Without kill from root). Terminal is hanged, you don't kill processes, waited process user is different (and sometimes user do not have root to even kill).

(In reply to Vitaly Chikunov from comment #4)
> (Ответ для Dmitry V. Levin на комментарий #3)
> > (In reply to Vitaly Chikunov from comment #2)
> > > I suggest user confirmation - kill (y/n) or wait longer.
> > 
> > Snatch terminal from remaining hasher processes?
> 
> Design is such that user cannot be asked?

If there is a terminal, everything is theoretically possible, but ...

> > > Also, what data could be lost in the hasher?
> > 
> > Any kind of data processed inside hasher.
> > 
> > For example, if the main process fails to wait for its child processes
> > properly,
> > the killing spree would terminate these processes prematurely.
> 
> Thanks. But, how would you resolve this situation otherwise? (Without kill
> from root). Terminal is hanged, you don't kill processes, waited process
> user is different (and sometimes user do not have root to even kill).

... root is not needed, the user can kill its hasher-priv processes at this stage, they have the same uid as the user and they are visible via ps.

> ... root is not needed, the user can kill its hasher-priv processes at this
> stage, they have the same uid as the user and they are visible via ps.

IC. It's worked. This is certainly non-obvious. But, the background process also got SIGKILL and terminal is messed up so I got to run `stty sane`.

So this solution, while exists and I didn't think of it, still as good as premature kill (and it's SIGKILL, not even SIGINT/SIGTERM which careful process could handle so save data).

(In reply to Vitaly Chikunov from comment #6)
> > ... root is not needed, the user can kill its hasher-priv processes at this
> > stage, they have the same uid as the user and they are visible via ps.
> 
> IC. It's worked. This is certainly non-obvious. But, the background process
> also got SIGKILL and terminal is messed up so I got to run `stty sane`.

That's because hasher-priv doesn't handle deadly signals, maybe it should handle them and restore the terminal.

> So this solution, while exists and I didn't think of it, still as good as
> premature kill (and it's SIGKILL, not even SIGINT/SIGTERM which careful
> process could handle so save data).

Those who kill hasher-priv this way should make sure the data is safe.
Alternatively, one can terminate chrootuid2.sh first.

But all these methods are hacks, I'd prefer to have an option for hsh-shell to wait for the specified number of seconds before calling it a day, or an option to specify an escape sequence similar to "ssh -e".