conmon writes oom file to cwd

[Paul Holzinger]

I have no idea if there is a reason for it but this seems rather strange behavior, why do we write the oom file to the cwd? This clutters the working directory of users with a random oom file in case of a oom container kill which makes no sense to a end user.

conmon/src/cgroup.c

Lines 331 to 334 in e21e7c8

 _cleanup_close_ int oom_fd = open("oom", O_CREAT | O_CLOEXEC, 0666); 
 if (oom_fd < 0) { 
 	nwarn("Failed to write oom file"); 
 } 

For podman something simple as
podman run --rm --memory 1m --oom-score-adj 1000 quay.io/libpod/testimage:20240123 sort /dev/urandom will reproduce the issue and writes it the cwd as podman does not change the cwd for conmon.

I tried to lookup the history and chased this all the way back to the inial commit, then continued in crio and eventually found cri-o/cri-o@7700a62

I am not sure did cri-o set a different cwd for each conmon instance so cri-o could just read this without conflicts?

IMO I like to remove this assuming cri-o does no depend on it? Using the persistent path should be better?
Alternatively do we have to change the cwd in podman before launching conmon? Not sure if this breaks anything.