Third Party Boot Flash Plugin Architecture

From unRAID
Jump to: navigation, search

This structure is now deprecated in favor of using unRAID Server OS Plugins.
I personally use a similiar structure substituting "custom" with "local" and duplicating the unix directory structure as needed, WeeboTech
The rest of this document is here for historical purposes until I update the suggestions.

The following is a proposed boot flash architecture to help support third party add ons. Its goal is to present a common structure to allow easy drop / plugins for the average user.

Currently this is proposed to occur on the boot flash drive in /boot.

Recommendations are to have a custom or named directory to mimic a common tree for usage.

The following directories would occur under /boot/custom as the starting root.

/boot/packages is the recommended directory for user downloaded packages from

/boot/custom/bin is the recommended directory for user created scripts and commands.

/boot/custom/etc/ is the recommended directory for user configurations which are to replace or be used in place of the system's /etc/ files. A Startup script can copy this tree onto to the normal root to put the files in place. Another choice is to alter the applications to access these files directly.

/boot/custom/etc/rc.d is the proposed directory for user supplied startup scripts. In this directory we can put third party startup/init scripts and/or replace system scripts. It should "probably" be called before emhttp is started up.

/boot/custom/etc/rc.d/init.d is the proposed directory for startup or control scripts that you want to exist, but not to run automatically.

In addition there have been recommendations for multiple user run levels based on unRAID's actual array status. These have not yet been implemented, as we do not at this time have the hooks in unRAID needed to invoke the scripts at the appropriate times.

These levels are

  • pre_array_start_onboot(1)
    • First time on boot before array is started (called only once per boot)
  • post_array_start_onboot(2)
    • First time on boot after array is started (called only once per boot)
  • pre_array_start(3)
    • This is similar to the first run level, only it's called when the "array is started, automatically and/or manually" It can be run one or more times depending on the change of state
  • post_array_start(4)
    • As above similar to 2, only it is called after all mounts have been made and the system is in a quiesced state ready for work.
  • pre_array_stop(5)
    • This is called when the array is stopped manually from the interface before te array is stopped. Functions might be to kill daemons that have open files on the mount.
  • post_array_stop(6)
    • This is called when the array has finally stopped and the disks are quiesced

These run levels could have simple names mimicking a sysv structure as in:


Or we could use long names as in


Here is how the proposed tree would look

!   |___rc.d/
!   !   |___init.d/
!   !   |___rc-post-array-start.d/
!   !   |___rc-post-array-start-onboot.d/
!   !   |___rc-post-array-stop.d/
!   !   |___rc-pre-array-start.d/
!   !   |___rc-pre-array-start-onboot.d/
!   !   |___rc-pre-array-stop.d/
!   |___share/
!   !   |___packages/