Identify files/processes that prevent remounting read-only
My system runs Debian Testing, and / is generally mounted as read-only.
The main problem with this is, every time I install something or update the system, I cannot remount the filesystem (I get the error: mount: / is busy) as read-only again.
Used command:mount -o remount,ro /dev/mapper/sda9_crypt /
I have searched for processes and file-locks (with lsof/fuser), but I have no idea what I have to specifically search for.
I do not want to reset the system after an update, just to be able to get it remounted read-only.
Therefore, I look for the key processes that I need to kill to make this possible.
files mount process open-files
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
add a comment |
My system runs Debian Testing, and / is generally mounted as read-only.
The main problem with this is, every time I install something or update the system, I cannot remount the filesystem (I get the error: mount: / is busy) as read-only again.
Used command:mount -o remount,ro /dev/mapper/sda9_crypt /
I have searched for processes and file-locks (with lsof/fuser), but I have no idea what I have to specifically search for.
I do not want to reset the system after an update, just to be able to get it remounted read-only.
Therefore, I look for the key processes that I need to kill to make this possible.
files mount process open-files
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54
add a comment |
My system runs Debian Testing, and / is generally mounted as read-only.
The main problem with this is, every time I install something or update the system, I cannot remount the filesystem (I get the error: mount: / is busy) as read-only again.
Used command:mount -o remount,ro /dev/mapper/sda9_crypt /
I have searched for processes and file-locks (with lsof/fuser), but I have no idea what I have to specifically search for.
I do not want to reset the system after an update, just to be able to get it remounted read-only.
Therefore, I look for the key processes that I need to kill to make this possible.
files mount process open-files
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
My system runs Debian Testing, and / is generally mounted as read-only.
The main problem with this is, every time I install something or update the system, I cannot remount the filesystem (I get the error: mount: / is busy) as read-only again.
Used command:mount -o remount,ro /dev/mapper/sda9_crypt /
I have searched for processes and file-locks (with lsof/fuser), but I have no idea what I have to specifically search for.
I do not want to reset the system after an update, just to be able to get it remounted read-only.
Therefore, I look for the key processes that I need to kill to make this possible.
files mount process open-files
files mount process open-files
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
edited Mar 8 '16 at 22:30
Gilles
541k12810951611
541k12810951611
asked Mar 8 '16 at 6:34
JeffJeff
262
asked Mar 8 '16 at 6:34
JeffJeff
262
asked Mar 8 '16 at 6:34
JeffJeff
262
262
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54
add a comment |
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54
add a comment |
2 Answers
2
active
oldest
votes
In the output of lsof /, in addition to files opened for writing (w suffix in the FD column), look for files marked (deleted). Files outside /var, /tmp (and /run, etc.) and home directories usually don't remain open for writing for a long time. But after an upgrade of some software, there may be some executable, library or data file that's still in use (open for reading or executing) by a running process that was started before the upgrade.
When a file is deleted but still open, that actually only removes its directory entry. The file itself is only deleted when it has no directory entry and it isn't open. That last part of deletion can't happen on a filesystem that's mounted read-only, so such a half-deleted file prevents remounting the filesystem as read-only just like a file open for writing does.
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ranlsofas root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.
– Gilles
Mar 9 '16 at 17:25
add a comment |
We can parse the output of lsof and filter to processes with writable file descriptors on the device. On my system, the FD is the 4th column, and it's suffixed with w or u for files opened for writing or read+write respectively:
lsof +f -- / | awk '$4 == "FD" || $4 ~ /[0-9][wu]$/'
The $4 == "FD" test is there just to pass the column headers through unmolested.
This will need adapting for your particular lsof implementation; there might be value in reading the Output for other programs section of the lsof manual page if you need a more portable solution.
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f268318%2fidentify-files-processes-that-prevent-remounting-read-only%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In the output of lsof /, in addition to files opened for writing (w suffix in the FD column), look for files marked (deleted). Files outside /var, /tmp (and /run, etc.) and home directories usually don't remain open for writing for a long time. But after an upgrade of some software, there may be some executable, library or data file that's still in use (open for reading or executing) by a running process that was started before the upgrade.
When a file is deleted but still open, that actually only removes its directory entry. The file itself is only deleted when it has no directory entry and it isn't open. That last part of deletion can't happen on a filesystem that's mounted read-only, so such a half-deleted file prevents remounting the filesystem as read-only just like a file open for writing does.
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ranlsofas root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.
– Gilles
Mar 9 '16 at 17:25
add a comment |
In the output of lsof /, in addition to files opened for writing (w suffix in the FD column), look for files marked (deleted). Files outside /var, /tmp (and /run, etc.) and home directories usually don't remain open for writing for a long time. But after an upgrade of some software, there may be some executable, library or data file that's still in use (open for reading or executing) by a running process that was started before the upgrade.
When a file is deleted but still open, that actually only removes its directory entry. The file itself is only deleted when it has no directory entry and it isn't open. That last part of deletion can't happen on a filesystem that's mounted read-only, so such a half-deleted file prevents remounting the filesystem as read-only just like a file open for writing does.
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ranlsofas root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.
– Gilles
Mar 9 '16 at 17:25
add a comment |
In the output of lsof /, in addition to files opened for writing (w suffix in the FD column), look for files marked (deleted). Files outside /var, /tmp (and /run, etc.) and home directories usually don't remain open for writing for a long time. But after an upgrade of some software, there may be some executable, library or data file that's still in use (open for reading or executing) by a running process that was started before the upgrade.
When a file is deleted but still open, that actually only removes its directory entry. The file itself is only deleted when it has no directory entry and it isn't open. That last part of deletion can't happen on a filesystem that's mounted read-only, so such a half-deleted file prevents remounting the filesystem as read-only just like a file open for writing does.
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
In the output of lsof /, in addition to files opened for writing (w suffix in the FD column), look for files marked (deleted). Files outside /var, /tmp (and /run, etc.) and home directories usually don't remain open for writing for a long time. But after an upgrade of some software, there may be some executable, library or data file that's still in use (open for reading or executing) by a running process that was started before the upgrade.
When a file is deleted but still open, that actually only removes its directory entry. The file itself is only deleted when it has no directory entry and it isn't open. That last part of deletion can't happen on a filesystem that's mounted read-only, so such a half-deleted file prevents remounting the filesystem as read-only just like a file open for writing does.
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
edited Mar 9 '16 at 17:26
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
answered Mar 9 '16 at 0:59
GillesGilles
541k12810951611
541k12810951611
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ranlsofas root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.
– Gilles
Mar 9 '16 at 17:25
add a comment |
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ranlsofas root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.
– Gilles
Mar 9 '16 at 17:25
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
I think there is a misunderstanding. The volume is always remounted as read-write before something is changed. Only then remount read-only done the works no longer. The output of "lsof / | grep deleted", shows nothing, but i still cant remount read-only. It probably seems better simply restart, or? Thanks.
– Jeff
Mar 9 '16 at 15:24
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ran
lsof as root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.– Gilles
Mar 9 '16 at 17:25
@Jeff I don't understand what misunderstanding you're referring to. I am describing the scenario where the volume is remounted read-write before changing something and afterwards remounting as read-only doesn't work. Files open for writing, and files that are deleted but still open, are the most common things that prevent remounting as read-only. If it's neither (you ran
lsof as root, right?), there are other reasons that are hard to investigate (e.g. a loop mount), but they're rare, I can't think of something that would typically happen during a software upgrade.– Gilles
Mar 9 '16 at 17:25
add a comment |
We can parse the output of lsof and filter to processes with writable file descriptors on the device. On my system, the FD is the 4th column, and it's suffixed with w or u for files opened for writing or read+write respectively:
lsof +f -- / | awk '$4 == "FD" || $4 ~ /[0-9][wu]$/'
The $4 == "FD" test is there just to pass the column headers through unmolested.
This will need adapting for your particular lsof implementation; there might be value in reading the Output for other programs section of the lsof manual page if you need a more portable solution.
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
add a comment |
We can parse the output of lsof and filter to processes with writable file descriptors on the device. On my system, the FD is the 4th column, and it's suffixed with w or u for files opened for writing or read+write respectively:
lsof +f -- / | awk '$4 == "FD" || $4 ~ /[0-9][wu]$/'
The $4 == "FD" test is there just to pass the column headers through unmolested.
This will need adapting for your particular lsof implementation; there might be value in reading the Output for other programs section of the lsof manual page if you need a more portable solution.
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
add a comment |
We can parse the output of lsof and filter to processes with writable file descriptors on the device. On my system, the FD is the 4th column, and it's suffixed with w or u for files opened for writing or read+write respectively:
lsof +f -- / | awk '$4 == "FD" || $4 ~ /[0-9][wu]$/'
The $4 == "FD" test is there just to pass the column headers through unmolested.
This will need adapting for your particular lsof implementation; there might be value in reading the Output for other programs section of the lsof manual page if you need a more portable solution.
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
We can parse the output of lsof and filter to processes with writable file descriptors on the device. On my system, the FD is the 4th column, and it's suffixed with w or u for files opened for writing or read+write respectively:
lsof +f -- / | awk '$4 == "FD" || $4 ~ /[0-9][wu]$/'
The $4 == "FD" test is there just to pass the column headers through unmolested.
This will need adapting for your particular lsof implementation; there might be value in reading the Output for other programs section of the lsof manual page if you need a more portable solution.
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
answered Feb 21 at 14:17
Toby SpeightToby Speight
5,34811031
5,34811031
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f268318%2fidentify-files-processes-that-prevent-remounting-read-only%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
mount -o remount,rw /dev/mapper/sda9_crypt /
– Svetlin Tonchev
Mar 8 '16 at 13:54