이벤트의 오래된 파일을 삭제하고 아카이브에서 실행 중인 내장 대상 루트 파일 시스템으로 새 파일을 복사하여 파일을 대체하는 간단한 업데이터 bash 스크립트가 있습니다. 이런 방식으로 스크립트는 시스템 파일을 업데이트할 뿐만 아니라 프로그램 스크립트 자체도 업데이트할 수 있습니다.
mount -o remount,rw /dev/rootfs /mount -o remount,ro /dev/rootfs /최근에는 R/W access()로 다시 마운트하고, 업데이트 작업을 수행하고, R/O access()로 다시 마운트하여 읽기 전용 파일 시스템을 처리하도록 스크립트를 확장했습니다 .
하지만 이 접근법은 실패했습니다. 일반적으로 스크립트는 첫 번째 실행(R/O 액세스로 다시 설치하는 경우) 또는 두 번째 실행(R/W 액세스로 다시 설치하는 경우)에서 실패합니다. 다음은 일반적인 오류 메시지입니다.
root@device:~# mount -o remount,rw /dev/rootfs /
EXT3-fs (mmcblk0p2): warning: couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead.
mount: mounting /dev/rootfs on / failed: Invalid argument
약간의 조사 후(예:https://stackoverflow.com/questions/7834667/self-deleting-bash-script) 문제는 파일 시스템에서 열린 파일을 삭제하는 방법의 메커니즘에 있다는 것을 깨달았습니다. 즉, 호출 시 파일의 inode에 대한 링크만 연결 해제되고 해당 파일을 사용하는 모든 프로그램이 파일을 닫으면 해당 inode가 나타내는 파일이 실제로 삭제됩니다. 따라서 R/O 모드로 다시 마운트하면 inode에 대한 링크가 사라지지만 inode 자체는 사라지지 않고 파일 시스템이 손상되어 나열된 오류가 발생합니다. 이 결론이 맞나요?
이제 제가 관심 있는 것은 이 문제를 올바르게 해결하는 방법입니다. R/O 모드로 다시 설치하고 시스템을 재부팅하지 않아도 괜찮을 것 같은데요? 그러나 R/O 모드로 다시 마운트하고 시스템 재부팅을 방지할 수 있는 더 나은 솔루션이 있습니까?
솔루션은 파일 시스템 유형과 독립적이어야 합니다. 특히 저는 ext3/ext4와 ubifs를 사용하고 있습니다.
편집하다:개별 서비스를 다시 시작할 필요가 없는 일반적인 솔루션(예: 시스템 파악)을 찾고 있습니다. 시스템을 다시 시작하는 것은 실제로 문제가 아니며, 업데이트 스크립트를 실행하기 전과 동일한 상태로 시스템을 되돌리는 것만으로도 올바른 것처럼 들립니다. 즉, 파일 시스템이 실행되기 전에 R/O였다면 아마도 R/O여야 할 것입니다. 그 후에도. 그러나 아마도 그러한 전제는 유효하지 않을 것입니다.