The ClusterServerParameterRefresher has a periodic job that runs internal transactions on the config server. The job currently isn't explicitly stopped on shutdown so a new transaction can start after mongos implicitly aborts transactions as part shutting down. The new transaction can get interrupted on mongos later during shutdown and that results in an open transaction on the config server. This can occur in sharding tests since ShardingTest.stop() shuts down the mongoses before the config server. When it occurs, it would get stuck trying shut down the config server because freezing a node involves doing fsync which requires taking the global S lock which cannot occur because the the IX lock is being held by the dangling transaction and in tests we use the transaction lifetime limit of 24 hours.