Bug 2035657

Summary: Pod termination time is longer than 5 minutes
Product: OpenShift Container Platform Reporter: Ilan Green <igreen>
Component: NodeAssignee: Sascha Grunert <sgrunert>
Node sub component: CRI-O QA Contact: Sunil Choudhary <schoudha>
Status: CLOSED DUPLICATE Docs Contact:
Severity: medium    
Priority: medium CC: aos-bugs, cback, dking, ealcaniz, joboyer, msekleta, nagrawal, openshift-bugs-escalate, sgrunert, smilner, walters
Version: 4.9   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-04 12:02:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ilan Green 2021-12-26 15:02:05 UTC 
Description of problem:
Pod termination time is longer than 5 minutes.
This bug is a followup of bz https://bugzilla.redhat.com/show_bug.cgi?id=2030029

While pods are no longer stuck in termination state - termination time maybe longer than 5 minutes (5 - 10) 
Hence opening this bz, as noted in https://bugzilla.redhat.com/show_bug.cgi?id=2030029#c39, to pursue / fine tune termination time

Version-Release number of selected component (if applicable):
ocp 4.9, 4.8

How reproducible:
Reproducible at the customer environment as described in https://bugzilla.redhat.com/show_bug.cgi?id=2030029#c0

Steps to Reproduce:
1.
2.
3.

Actual results:
pods termination is longer than 5 minutes

Expected results:
Have pods terminate faster, less than 5 minutes 
the faster the better

Additional info:

Please let us know required data collection which will help pin pointing the issue
Comment 1 Peter Hunt 2022-01-07 21:56:43 UTC 
Sascha, can you take a look at this? we have to find why dbus connections are going into the void (If i were to guess, I would guess the dbus library is exec'ing something, and that exec'd process is falling into the wrong cpuset)