search

teemtee / tmt

Test Management Tool
MIT License
79 stars 117 forks source link

rstrnt-sync-* apparently not compatible with tmt #2749

Open happz opened 4 months ago

happz commented 4 months ago

When called for the first time, rstrnt-sync-set spawns a background process that listens on TCP & Unix sockets for incoming sync changes. However, when a test finishes, tmt & SSH cooperate to avoid leaving leftover processes on the guest, and this means the said background process would be killed. Probably quite strongly, as it does not clean up the Unix socket, and any subsequent call to rstrnt-sync-set on the same guest, e.g. from a later test, will get stuck on trying to connect to the now dead background sync manager process.

rstrnt-sync could do a better job when starting the background process, it's still part of the test's process group, and as such it's "garbage collected" when the test finishes.

What to do with this situation? Do we want to provide compatible aliases? Or write a note & recommend other libraries?

Related issue https://issues.redhat.com/browse/TFT-2395

thrix commented 4 months ago

@happz we want to strive for 100% compatibility with Beaker. So we should make it work.

We might want to provide our own rstrnt-sync-set that makes sure the background process correctly handles the signal handling and exists gracefully on such an event, cleaning up the leftover Unix socket.

thrix commented 4 months ago

notes from the tmt hacking discussion:

Can Jishi answer how many tests are affected by this, are there a lot of them?

kkaarreell commented 4 months ago

According to restraint docs

States are scoped to the current task. That is, states set by the current task will have no effect in subsequent tasks.

Even if we fix the process killing issue, does it mean that tmt would also mimic restraint behavior with respect to the above to avoid conflicts across tests?