Bug 41978

Summary:	Impossible to exit hsh-shell if processes left in background
Product:	Sisyphus	Reporter:	Vitaly Chikunov <vt>
Component:	hasher	Assignee:	Dmitry V. Levin <ldv>
Status:	NEW ---	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P5	CC:	at, glebfm, iv, ldv, placeholder
Version:	unstable
Hardware:	x86
OS:	Linux

Description Vitaly Chikunov 2022-02-17 02:00:22 MSK

When developing or debugging something in the hasher (as in best practices) some process could be inadvertently left in background, causing failure exiting hsh-shell and working terminal hang. Example:
```
$ hsh-shell
builder@x86_64:/.in$ sleep 1234 &
[1] 3978262
builder@x86_64:/.in$ exit
logout
```
Hangs there. It does not respond to ^C or ^Z, user cannot kill stray process, because it's different user.

Would be more rational if hasher kills such processes on exit. (Possible after user y/n request).

Or I'm missing something?

Comment 1 Dmitry V. Levin 2022-02-19 19:09:35 MSK

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.

Comment 2 Vitaly Chikunov 2022-02-19 19:49:27 MSK

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

Also, what data could be lost in the hasher?

Comment 3 Dmitry V. Levin 2022-02-19 20:03:16 MSK

(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.

Comment 4 Vitaly Chikunov 2022-02-19 20:09:19 MSK

(Ответ для 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).

Comment 5 Dmitry V. Levin 2022-02-19 20:40:31 MSK

(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.

Comment 6 Vitaly Chikunov 2022-02-20 00:59:31 MSK

> ... 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).

Comment 7 Dmitry V. Levin 2022-02-20 01:26:54 MSK

(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".