7

I have a script that gathers debugging info from the running environment and I need to figure out were I can save that info.

It may be called anytime:

  • at boot
  • when the system is running
  • at shutdown, etc...
  • and by any user or process / service.

I need a folder that is accessible at all time to EVERYTHING.

Does that exist already? If not how can I make it happen?
Since this is for debugging purposes I don't care about security, it'll all be removed before hitting prod.

TCZ8
  • 1,069

4 Answers4

8

/tmp, but the data stored there will be deleted upon reboot

Creek
  • 5,062
  • 6
    /var/tmp/ is another option, files there usually persist for longer. See http://unix.stackexchange.com/questions/30489/what-is-the-difference-between-tmp-and-var-tmp – Graeme Apr 30 '14 at 14:24
7

You can make a new top level directory (under /) e.g. named test and set the permissions appropriately:

sudo mkdir /test
sudo chmod 777 /test

by making it a top level directory you don't have to worry about permissions of intermediate directories.

In code/scripts I would test if the directory exists and if not existent, I would not create it, assuming this was a production system. Make sure that any routines trying to write/read from the directory would fail graciously (in case I forgot to remove some of the testing code for the production system).

Anthon
  • 79,293
  • Thank you for the additional info. You answered the 2nd part of my question, its sad we cant choose multiple answers. – TCZ8 Apr 30 '14 at 16:05
2

You can also use /dev/shm/, this is space allocated in memory. The space is limited by the quantity of RAM but since it's in the memory there's no latency, contrary to /tmp/ on an hard drive (and not with the SSD because of their near-to-zero latency). So it can be an alternative to /dev/shm/ if you need to store a small amount of data. On some Linux distributions it can be located at /run/shm/.

See tmpfs for more information.

A.L
  • 1,586
1

@Anthon's answer is probably the best that meets your stated requirements, but there is one shortcoming that can not be overcome by his or @Creeks answer ind that is before and during fsck. In most cases unix like systems boot with their root partition read only, check it for errors, and remount it read write if everything is ok. This is a good idea but it leaves a window in which your tool does not work. If this does not bother you @Anthon is your man. If you need to work during this window the only viable solution is a second computer and a couple serial ports. This has a couple disadvantages including added hardware requirements and lack of speed, but has the chief advantage that serial ports are available sooner (with the notable exception of usb serial adapters I most serial ports are available before init)

hildred
  • 5,829
  • 3
  • 31
  • 43