Failure in changing the docker restart policy

[Lorsh]

crun works great with docker when trying to bring the containers up. However, when we try to run something like this command on a running container:
docker update --restart always <container_name>
It runs into this issue:

Error response from daemon: Cannot update container 4d8e0414eed469e0afdd995f70864144f02a5f1d79fa60ebac2c4eae9d78fdee: /mnt/config/docker/runtimes/crun did not terminate successfully: exit status 1: Setting memory.limit_in_bytes to 0
writing file `memory.limit_in_bytes`: Device or resource busy

When looking at gdb, I see that crun tries to set limit_in_bytes to 0:

#3  0x000000000045544c in write_memory (dirfd=dirfd@entry=4, cgroup2=cgroup2@entry=false, memory=memory@entry=0x497a30, err=err@entry=0x7ffcf0fddb98)
at src/libcrun/cgroup-resources.c:707
707	  sleep(900);
(gdb) list
702	  if (! memory->limit_present)
703	    return 0;
704	
705	  limit_buf_len = cg_itoa (limit_buf, memory->limit, cgroup2);
706	  libcrun_warning("Setting memory.limit_in_bytes to %s",limit_buf);
707	  sleep(900);
708	  return write_cgroup_file (dirfd, cgroup2 ? "memory.max" : "memory.limit_in_bytes", limit_buf, limit_buf_len, err);
709	}
710	
711	static int
(gdb) print memory
$1 = (runtime_spec_schema_config_linux_resources_memory *) 0x497a30
(gdb) print *memory
$2 = {
  kernel = 0,
  kernel_tcp = 0,
  limit = 0,
  reservation = 0,
  swap = 0,
  swappiness = 0,
  disable_oom_killer = false,
  use_hierarchy = false,
  check_before_update = false,
  _residual = 0x0,
  kernel_present = 1,
  kernel_tcp_present = 0,
  limit_present = 1,
  reservation_present = 1,
  swap_present = 0,
  swappiness_present = 0,
  disable_oom_killer_present = 0,
  use_hierarchy_present = 0,
  check_before_update_present = 0
}

Note that I added the sleep and the "libcrun_warning("Setting memory.limit_in_bytes to %s",limit_buf);" line for debugging purposes.

Is this a known issue with crun and docker?
This is running with cgroup1 and crun version 1.8.7 and kernel version 5.10.

[giuseppe]

thanks for the report, no this is not a known issue