It turns out that the way SocketIO (which is the class you get from)
`sock.makefile` doesn't _actually_ close the socket when you close the IO
object, which normally is fine as the socket won't be around and will clean up
nicely, but due to forking and us _actually_ wanting to close the socket, we
need to be a bit more careful about how we do this.

It also turns out I misunderstood when `set_inheritable` applies. It is not
about when forking, but specifically only when execing. So I've removed that
setting as we don't need it.

Closes #46048, and relates to #47294 (it might close it, it might not, unsure
at this point)

This method has been replaced by `handle_removed_files` and `deactivate_deleted_dags`
method. Its presents now causes issues as it deactivates DAGs wrongly. `handle_removed_files`
is a better method more suited to dag bundles as the file's processor is also terminated.

Also removed used config variable in scheduler
Closes: apache#47294

This method has been replaced by `handle_removed_files` and `deactivate_deleted_dags`
method. Its present now causes issues as it deactivates DAGs incorrectly. `handle_removed_files`
is a better method more suited to dag bundles as the file's processor is also terminated.

Also removed used config variable in scheduler
Closes: apache#47294

This method has been replaced by `handle_removed_files` and `deactivate_deleted_dags`
method. Its present now causes issues as it deactivates DAGs incorrectly. `handle_removed_files`
is a better method more suited to dag bundles as the file's processor is also terminated.

Also removed unused config variable in scheduler and config.yml
Closes: apache#47294

This method has been replaced by `handle_removed_files` and `deactivate_deleted_dags`
method. Its present now causes issues as it deactivates DAGs incorrectly. `handle_removed_files`
is a better method more suited to dag bundles as the file's processor is also terminated.

Also removed unused config variable in scheduler and config.yml
Closes: apache#47294

We currently use Psutil's create_time for process start time,
which gives a different time than the time we use to check process
duration(which comes from time.monotonic). This leads to the
processor timing out after a while due to the large (false)difference
in time recorded, especially when the laptop is hibernated.

Process time should not depend on the system's time clock, and I guess that's what happened here.

Closes: apache#47937, Closes: apache#47294

We currently use Psutil's create_time for process start time,
which gives a different time than the time we use to check process
duration(which comes from time.monotonic). This leads to the
processor timing out after a while due to the large (false)difference
in time recorded, especially when the laptop is hibernated.

Process time should not depend on the system's time clock, and I guess that's what happened here.

Closes: apache#47937, Closes: apache#47294

We currently use Psutil's create_time for process start time,
which gives the time the process started using the system clock. We can use
time.time to track when the process started processing the files instead.

In breeze, once the laptop hibbernates, you would have to restart the dag
processor but this fixes it. Since this does not happen in other deployments,
we suspect that this issue is peculiar to breeze.

Closes: apache#47937, Closes: apache#47294

We currently use Psutil's create_time for process start time,
which gives the time the process started using the system clock. We can use
time.time to track when the process started processing the files instead.

In breeze, once the laptop hibbernates, you would have to restart the dag
processor but this fixes it. Since this does not happen in other deployments,
we suspect that this issue is peculiar to breeze.

Closes: apache#47937, Closes: apache#47294

We currently use Psutil's create_time for process start time,
which gives the time the process started using the system clock. We can use
time.time to track when the process started processing the files instead.

In breeze, once the laptop hibbernates, you would have to restart the dag
processor but this fixes it. Since this does not happen in other deployments,
we suspect that this issue is peculiar to breeze.

Closes: apache#47937, Closes: apache#47294