2

I did sudo mv /tmp /var/lib/apt/lists not realizing that it would move the whole folder and not just the contents.

I since do (as suggested in Accidentally deleted tmp folder)

sudo mkdir -m 1777 /tmp

on startup, but after a while it disappears again. What can I do? how can I debug this?

It seems that /tmp is renamed to /snapshot.0 (or with a higher index if other snapshots already exist).

Restart does not solve it. But shutting down without a /tmp isn't a problem either, on startup a new /tmp is there. However within 4 minutes it is renamed to another snapshot.

What happens without /tmp:

  • no tab completion in bash (sometimes)
  • programs such as chromium-browser and system monitor don't start
  • apt-get seems to rely on /tmp as well

I currently execute sudo mv /snapshot.0 /tmp whenever /tmp disappears.

Experiments:

I start the computer(as we will see /tmp is still there apparently it survived restart) and open a terminal where I execute:

$ while true; do 
   t=$(date +%H:%M:%S);      #timestamp as hour minute seconds
   date;ls -lt / | head -3;  print out date and most recent folders in /
   ls -l /tmp        > ~/Desktop/ls.tmp.log.${t}; 
   ls -l /snapshot.0 > ~/Desktop/ls.snap.log.${t}; 
   sleep 60; 
done;

I do nothing else! log in terminal:

Di 23. Jun 19:44:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
drwxr-xr-x  34 root root       1000 Jun 23 19:42 run
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:45:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:46:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:47:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:48:12 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:44 tmp
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/snapshot.0': No such file or directory
Di 23. Jun 19:49:13 CEST 2020
total 2097264
drwxrwxrwt  18 root root       4096 Jun 23 19:48 snapshot.0
dr-xr-xr-x  13 root root          0 Jun 23 19:44 sys
ls: cannot access '/tmp': No such file or directory

So within 5 minutes /tmp has been renamed to /snapshot.0.

there is no difference between ls.tmp.log.19:4[4-8]:12 There is also no difference between ls.tmp.log.19:48:12 and ls.snap.log.19:49:13 so it can't be the content of /tmp.

Progress:

While I was hoping for a solution that makes things as they were before(without reinstalling the system) Giorgos Saridakis' suggestion of symlinks does work helps a lot. However I still can't start system monitor:

$ gnome-system-monitor 
cannot create temporary directory for the root file system: Permission denied

despite having all permissions set:

$ ls -lt /
total 2097264
drwxrwxrwt   8 root root       4096 Jun 27 15:21 snapshot.0
-rw-r--r--   1 root root          0 Jun 27 15:10 lifesign
...
lrwxrwxrwx   1 root root         11 Jun 23 22:12 tmp -> /snapshot.0

I guess I'll have to write a demon after all...

I wrote a script:

#!/bin/bash
while true;
do
    if [ ! -d "/tmp" ];
    then mv /snapshot.0  /tmp 2>> /home/t/tmp.rename.bg.err;
     date >> /home/t/tmp.rename.bg.log;
    fi;
    sleep 10;
done

that is executed with

sudo bash tmp.rename.sh &

after login. It's not ideal but I don't have to get into writing daemons just yet.

user2740
  • 1,087
  • 1
  • 13
  • 23

2 Answers2

2

It seems you've stumbled on a persistent part of the Kernel, I believe this is not solvable in the proper way.

In the absence of will to reinstall the whole system, why don't you try creating a symbolic (or a hard) link from /snapshot.0 to /tmp:

sudo ln -s /snapshot.0 /tmp

If that doesn't work, I would make a small daemon to constantly check if /tmp is there and create it, if not found (with lock permissions maybe).

Difficult situation, I sympathize :)

Giorgos Saridakis
  • 736
  • 1
    Hmm, I was really hoping I didn't have to reinstall the system... Do you think a version upgrade might fix it? How should I go into the next upgrade, with /tmp deleted or symlinked? – user2740 Jun 26 '20 at 17:38
  • Maybe a kernel update will fix things, but who can say ? if the links don't work (supposing that maybe a hard link will keep /tmp alive, that's the idea), apart from a system upgrade, a simple daemon will do the job. It's not perfect of course, but you could live with it – Giorgos Saridakis Jun 26 '20 at 18:07
  • Giorgos, what do you mean by "a persistent part of the kernel"? Are you saying this regular rename is a kernel bug? It's certainly not normal behaviour and I can't find it documented as a side-effect anywhere. (The closest I can find is snapper, but that's only on a match for snapshot.0.) Thanks – Chris Davies Jun 29 '20 at 13:25
  • 1
    It appears the kernel seeks to locate a given i-node for /tmp and removes the new /tmp created again and again. This would certainly not be a kernel bug, rather a security measure, which probably doesn't have to do with /tmp alone. I am simply interpreting what is observed roaima and making the best guess from that perspective. – Giorgos Saridakis Jun 29 '20 at 13:51
0

Just delete the create one after booting and make a new directory of tmp as followed:

sudo mkdir -m 1777 /tmp
chown root:root /tmp

here -m is called mode of creation of a directory,which Set the file permission bits of the newly-created directory to the specified mode value.

After executing the above command, Now run the command below to check the permissions of the directory.

ls -ld /tmp

and It should be looking like this

Screenshot

Aravindha Hariharan
  • 126