The /usr/sbin file not a symlink when it's causing an error. I'm guessing that it's a hard link but that the package upgrade is somehow deleting the /sbin directory entry (because it's the only one listed in the dpkg -L output) and building a new inode for the new file contents, but leaving the /usr/sbin entry pointing to the old inode. Our solution has been to delete the old version in /usr/sbin and replace it with a symlink, but this might affect more Docker users who run on release-updated systems. I did find some somewhat recent references to that strconv.Atoi error for docker users, so I expect others are having the same problem, which is why I'm reporting it here. Ideally you would create a package update that in the post-update script tests whether the /usr/sbin entry is a regular file/hard link or a symlink, and deletes the existing entry if it's not a symlink before recreating it as a symlink.
The /usr/sbin file not a symlink when it's causing an error. I'm guessing that it's a hard link but that the package upgrade is somehow deleting the /sbin directory entry (because it's the only one listed in the dpkg -L output) and building a new inode for the new file contents, but leaving the /usr/sbin entry pointing to the old inode. Our solution has been to delete the old version in /usr/sbin and replace it with a symlink, but this might affect more Docker users who run on release-updated systems. I did find some somewhat recent references to that strconv.Atoi error for docker users, so I expect others are having the same problem, which is why I'm reporting it here. Ideally you would create a package update that in the post-update script tests whether the /usr/sbin entry is a regular file/hard link or a symlink, and deletes the existing entry if it's not a symlink before recreating it as a symlink.