files created then deleted at every second in tmp directory
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp
I managed to catch the created files:
-rw------- 1 root root 0 Apr 2 19:37 YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6
or another example:
-rw------- 1 root root 0 Apr 2 19:44 AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2
It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.
What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD
Thank you!
UPDATE
The question is about when not having /tmp in RAM (no tmpfs).
The guilty software is x2goserver.service otherwise a must have one.
files tmp
|
show 6 more comments
By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp
I managed to catch the created files:
-rw------- 1 root root 0 Apr 2 19:37 YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6
or another example:
-rw------- 1 root root 0 Apr 2 19:44 AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2
It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.
What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD
Thank you!
UPDATE
The question is about when not having /tmp in RAM (no tmpfs).
The guilty software is x2goserver.service otherwise a must have one.
files tmp
2
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
2
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
2
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.
– Peter Cordes
Apr 2 at 19:07
1
great - it’s a must have
– adrhc
2 days ago
2
@PeterCordes I'm not sure that the statement "/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install,/tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs
– Charles Green
yesterday
|
show 6 more comments
By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp
I managed to catch the created files:
-rw------- 1 root root 0 Apr 2 19:37 YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6
or another example:
-rw------- 1 root root 0 Apr 2 19:44 AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2
It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.
What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD
Thank you!
UPDATE
The question is about when not having /tmp in RAM (no tmpfs).
The guilty software is x2goserver.service otherwise a must have one.
files tmp
By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp
I managed to catch the created files:
-rw------- 1 root root 0 Apr 2 19:37 YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6
or another example:
-rw------- 1 root root 0 Apr 2 19:44 AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2
It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.
What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD
Thank you!
UPDATE
The question is about when not having /tmp in RAM (no tmpfs).
The guilty software is x2goserver.service otherwise a must have one.
files tmp
files tmp
edited yesterday
adrhc
asked Apr 2 at 16:43
adrhcadrhc
16017
16017
2
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
2
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
2
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.
– Peter Cordes
Apr 2 at 19:07
1
great - it’s a must have
– adrhc
2 days ago
2
@PeterCordes I'm not sure that the statement "/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install,/tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs
– Charles Green
yesterday
|
show 6 more comments
2
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
2
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
2
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.
– Peter Cordes
Apr 2 at 19:07
1
great - it’s a must have
– adrhc
2 days ago
2
@PeterCordes I'm not sure that the statement "/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install,/tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs
– Charles Green
yesterday
2
2
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
2
2
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
2
2
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why
/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.– Peter Cordes
Apr 2 at 19:07
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why
/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.– Peter Cordes
Apr 2 at 19:07
1
1
great - it’s a must have
– adrhc
2 days ago
great - it’s a must have
– adrhc
2 days ago
2
2
@PeterCordes I'm not sure that the statement "
/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install, /tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs– Charles Green
yesterday
@PeterCordes I'm not sure that the statement "
/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install, /tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs– Charles Green
yesterday
|
show 6 more comments
3 Answers
3
active
oldest
votes
I suggest installing and running fnotifystat to detect the process that is creating these files:
sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp
You will see process that is doing the open/close/read/write activity something like the following:
Total Open Close Read Write PID Process Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
add a comment |
Determine which program/process is touching files
You can use tools such as lsof
to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:
$ sudo fnotifystat -i /tmp
Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha
).
Put /tmp
into RAM instead of disk
If you desire, you can put your /tmp
directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.
$ sudo vim /etc/fstab
...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...
$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)
If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper
(sometimes tmpwatch
) to be more aggressive.
add a comment |
very undesirable one on a SSD
You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.
Furthermore, even if you had a physical backing store for your /tmp
filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.
So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.
– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2faskubuntu.com%2fquestions%2f1130673%2ffiles-created-then-deleted-at-every-second-in-tmp-directory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I suggest installing and running fnotifystat to detect the process that is creating these files:
sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp
You will see process that is doing the open/close/read/write activity something like the following:
Total Open Close Read Write PID Process Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
add a comment |
I suggest installing and running fnotifystat to detect the process that is creating these files:
sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp
You will see process that is doing the open/close/read/write activity something like the following:
Total Open Close Read Write PID Process Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
add a comment |
I suggest installing and running fnotifystat to detect the process that is creating these files:
sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp
You will see process that is doing the open/close/read/write activity something like the following:
Total Open Close Read Write PID Process Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)
I suggest installing and running fnotifystat to detect the process that is creating these files:
sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp
You will see process that is doing the open/close/read/write activity something like the following:
Total Open Close Read Write PID Process Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)
answered Apr 2 at 16:55
Colin Ian KingColin Ian King
12.6k13848
12.6k13848
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
add a comment |
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
1
1
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
Postscript: I'm the author of this tool: kernel.ubuntu.com/~cking/fnotifystat
– Colin Ian King
2 days ago
1
1
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
And you are also the first who answered the question (though no longer visible that). It's a good tool by the way.
– adrhc
2 days ago
add a comment |
Determine which program/process is touching files
You can use tools such as lsof
to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:
$ sudo fnotifystat -i /tmp
Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha
).
Put /tmp
into RAM instead of disk
If you desire, you can put your /tmp
directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.
$ sudo vim /etc/fstab
...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...
$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)
If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper
(sometimes tmpwatch
) to be more aggressive.
add a comment |
Determine which program/process is touching files
You can use tools such as lsof
to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:
$ sudo fnotifystat -i /tmp
Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha
).
Put /tmp
into RAM instead of disk
If you desire, you can put your /tmp
directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.
$ sudo vim /etc/fstab
...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...
$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)
If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper
(sometimes tmpwatch
) to be more aggressive.
add a comment |
Determine which program/process is touching files
You can use tools such as lsof
to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:
$ sudo fnotifystat -i /tmp
Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha
).
Put /tmp
into RAM instead of disk
If you desire, you can put your /tmp
directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.
$ sudo vim /etc/fstab
...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...
$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)
If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper
(sometimes tmpwatch
) to be more aggressive.
Determine which program/process is touching files
You can use tools such as lsof
to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:
$ sudo fnotifystat -i /tmp
Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha
).
Put /tmp
into RAM instead of disk
If you desire, you can put your /tmp
directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.
$ sudo vim /etc/fstab
...
# tmpfs in RAM
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
...
$ sudo mount /tmp
$ mount | grep tmp # Check /tmp is in RAM
tmpfs on /tmp type tmpfs (rw,noatime)
If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper
(sometimes tmpwatch
) to be more aggressive.
edited Apr 2 at 17:02
answered Apr 2 at 16:57
earthmeLonearthmeLon
6,6281951
6,6281951
add a comment |
add a comment |
very undesirable one on a SSD
You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.
Furthermore, even if you had a physical backing store for your /tmp
filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.
So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.
– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
add a comment |
very undesirable one on a SSD
You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.
Furthermore, even if you had a physical backing store for your /tmp
filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.
So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.
– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
add a comment |
very undesirable one on a SSD
You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.
Furthermore, even if you had a physical backing store for your /tmp
filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.
So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.
very undesirable one on a SSD
You tagged your question with tmpfs, so it is not quite clear to me how this relates to SSD at all. Tmpfs is an in-memory (or more precisely, in-block-cache) filesystem, so it will never hit a physical disk.
Furthermore, even if you had a physical backing store for your /tmp
filesystem, unless you have a system with only a couple of kilobytes of RAM, those short-lived files will never hit the disk, all operations will happen in the cache.
So, in other words, there is nothing to worry about since you are using tmpfs, and if you weren't, there still would be nothing to worry about.
answered 2 days ago
Jörg W MittagJörg W Mittag
1786
1786
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.
– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
add a comment |
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.
– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
I keep the /tmp in RAM so by mistake I tagged also with my current fs type (tmpfs). I removed it now but I find you're answer useful too so 1 up from me.
– adrhc
2 days ago
@adrhc: If your
/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.– Jörg W Mittag
2 days ago
@adrhc: If your
/tmp
is in RAM, then it has nothing whatsoever to do with your SSD, so it is neither desirable nor undesirable but actually completely unrelated.– Jörg W Mittag
2 days ago
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
I agree but the question is about when not having /tmp in RAM. It just happened that I had /tmp in RAM; still, the problem intrigued me.
– adrhc
yesterday
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f1130673%2ffiles-created-then-deleted-at-every-second-in-tmp-directory%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
2
"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?
– Rinzwind
Apr 2 at 16:54
2
/tmp may not necessarily be tmpfs, so it's a valid question
– Colin Ian King
Apr 2 at 16:56
2
Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why
/tmp
is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.– Peter Cordes
Apr 2 at 19:07
1
great - it’s a must have
– adrhc
2 days ago
2
@PeterCordes I'm not sure that the statement "
/tmp
is normally on tmpfs" is valid for a normal Ubuntu user - Just using the default Ubuntu install,/tmp
is on disk and the OP would need to create the appropriate fstab entries to put it into a tmpfs– Charles Green
yesterday