I am trying to create an init script which queries losetup -f for a free loop device. Within the init script I have a start() which queries losetup -f for the free loop device to setup some stuff, and there is also a stop().

The problem I can't figure out is how can I store the output of losetup -f in a persistent matter which is safe from user accidents (overwriting environment variables, etc) so that when stop() is called at any point I can have access to this particular init scripts loop device that it was assigned.

The reason I need persistence on which loop device is assigned is that there are 2-3 init scripts which are going to be dealing with loop devices (at least 2 loop devices per init script) and each needs to keep track of itself.

Should I assign the output of the multiple losetup -f to a file so that I can read them back via loop when I need to detach/work with them? If so what is a standard directory for this kind of data.

  • Store it in a file under /var/run, or its newer equivalent /run.
    – Mikel
    Jun 20 '15 at 19:29

As per the comments I have created a solution:

start() {
    loop=$(losetup -f)
    echo "$loop" > /var/run/init-script-name.loop
    #continue to use $loop as the reference to your loop device

stop() {
    loop=$(cat /var/run/init-script-name.loop)
    rm /var/run/init-script-name.loop
    #continue to use $loop as the reference to this scripts loop device

This allows each init script to save its loop device to a file that it can reference if it needs to obtain the device it was assigned at a later date. If multiple devices are needed you can echo them all into the file (one per line) and use while read -r /path/to/file to generate an array like structure which you can iterate over.


Maybe this could help.

Storing the vars,

declare -p var_name another_var more_vars > path_to_init_file


source path_to_init_file

Just discovered this great simple project (a rewritten fork). Looks perfect.


  • Tiny key-value database
  • Configurable database directory (default: ~/.kv-sh)
  • Used by importing functions via $ . ./kv-sh
  • Full database dump/restore
  • Support for secondary read-only defaults database
    . ./kv-sh                  # import kv-sh functions (use default database directory; see
                                 configuration environment variables for available options)
    kvset <key> <value>        # assign value to key
    kvget <key>                # get value of key
    kvdel <key>                # delete key
    kvexists <key>             # check if key exists
    kvkeys {-l|-d|-a}          # list all keys (-l local only, -d default only, -a all (default))
    kvlist {-a}                # list all key/value pairs (-a all keys, including default)
    kvdump {-a}                # database dump (-a all keys, including default)
    kvimport                   # database import (overwrite)
    kvrestore                  # database restore (clear and restore)
    kvclear                    # clear database

Defaults database

kv-sh supports secondary read-only defaults database. If enabled, keys-value pairs from default value database are returned if local value is not specified.

Enable defaults database by setting DB_DEFAULTS_DIR:

DB_DIR="/tmp/.kv" DB_DEFAULTS_DIR="/tmp/.kv-default" . ./kv-sh

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.