Jump to content

How to set environment variable at startup?


WannaTheater

Recommended Posts

In my quest for a replication solution, I am still trying to get Unison working on unraid. (I have been unable to find a docker image, let alone have any idea how to get it up and running).

I have modified \\tower\flash\config\go to include the startup command:  (the Unison executable is on my boot drive).

 

# Start Unison
/boot/unison -socket 1111 &

 

Unison does start and work properly for the most part.  It places some sync files *someplace*, but these are deleted after an unraid reboot, causing syncing to start from scratch (hours), vs. incrementally.   

 

From the manual:

The .unison Directory

Unison stores a variety of information in a private directory on each host. If the environment variable UNISON is defined, then its value will be used as the name of this directory. If UNISON is not defined, then the name of the directory depends on which operating system you are using. In Unix, the default is to use $HOME/.unison. In Windows, if the environment variable USERPROFILE is defined, then the directory will be $USERPROFILE\.unison; otherwise if HOME is defined, it will be $HOME\.unison; otherwise, it will be c:\.unison.

 

I believe $HOME is /root on unraid.  I have created a directory where I would like my unison sync files to be stored, and remain after an Unraid shutdown: \\tower\disk4\appdata\.unison

 

Questions:

1) Is "\\tower\flash\config\go" run after disks are mounted?

 

2) If so, can I modify the "go" file to set the environment variable like this:

UNISON=/mnt/disk4/appdata/.unison -or- 

set UNISON=/mnt/disk4/appdata/.unison  (My linux is not good!)

 

3) Any risk to what I am trying to do?  (i.e. does having an executable write directly to a /mnt/disk4 directory compromise the integrity of unraid file system?)  (I normally just use window shares for copy/paste, never programatically modify data on my unraid server)

 

Thanks for any help you can offer.

Link to comment

The array is NOT started at the time the ‘go’ file is executed.  

 

I would suggest that rather than trying to do this via amending the ‘go’ file you would be better of using the User Scripts plugin as that way you can schedule the script to be run once the array is started.

Link to comment

This is not exactly the job of a user launched script, but a login script.

 

As you have not stated how unison is being run, the easiest is probably to

You can use user scripts plugin to run this script on array startup

#!/bin/bash

cat <<EOF > /etc/profile.d/unison.sh
export UNISON=/mnt/disk4/appdata/unison
EOF

This would then create a login script that is run when you login to a shell, and it sets the UNISON environment variable to what you want.

Also, there is no need to use .unison as the directory. Placing a . in from just makes it harder to find later on.

 

 

Link to comment

Thanks for the feedback-  it helps.

 

For clarification, I am trying to accomplish the following, at the time my unraid server boots up: 

1) Set an environment variable named UNISON to /mnt/disk4/appdata/unison.   From itimpi, it doesn't appear that I can do this in the "go" file, as the array has not started (directory location not available).

2) Start the executable named Unison and run in background, with a specific socket number.  I currently have the Unison executable file located the unraid flash drive (7M).  It is currently being started through the "go" file with the following command:

# Start Unison
/boot/unison -socket 1111 &

 

The issue I am having is once "/boot/unison -socket 1111 &" is kicked off, if there is no UNISON environment variable set, Unison defaults to looking for its files in "$home/.unison."  If that directory is not there, it will create it.  I need it to point to a constant location, as it accesses files there, writes logs, etc.  So on every Unraid reboot, this directory gets recreated with nothing in it.

 

ken-ji-

It looks like you were mentioning something about a login script, but then mention a user script.  Got me confused.

Can this somehow be done WITHOUT me logging on?  I am looking to have it done at startup, like an "autoexec.bat" from the old days :)

 

I would even prefer to get the "Unison" executable off the flash drive, and put into a location on the array (perhaps even /mnt/disk4/appdata/unison)

Link to comment

After reading up and installing the user script, I am thinking this may work:

 

1) Create a directory on flash drive config/plugins/user.scripts/scripts/StartUnison

2) Create a file in that directory called StartUnison.sh with the following contents:

#!/bin/bash

#Set UNISON environment variable
export UNISON=/mnt/disk4/appdata/unison

#Start Unison process in background (assuming I create a /mnt/disk4/bin directory and copy the Unison executable to it)
/mnt/disk4/bin/unison -socket 1111 &

2) When configuring the script in the Unraid web interface, schedule script to run at STARTUP of array.

The assumption here is that it runs just after all the discs are mounted, so it will find the Unison executable.

I am unsure if I should run the StartUnison.sh in background or foreground. (Linux is not good, but I am assuming that when the StartUnison.sh completes, it will not kill the actual unison prcess that is running in background with "&')  

 

Does that seem correct? 

 

Thank You!

Link to comment

OK-  For the most part this now works.  But this created a new issue-  I cannot stop the array.  It gets hung up unmounting shares.  In order to fix the issue, I need to telnet to the unraid server, and manually kill the Unison process running in the background.  Perhaps I also need a StopUnison.sh script that determines the process it, and kills it, to be scheduled on Array Stop.  Now to research the syntax...

Link to comment
2 hours ago, WannaTheater said:

After reading up and installing the user script, I am thinking this may work:

 

1) Create a directory on flash drive config/plugins/user.scripts/scripts/StartUnison

2) Create a file in that directory called StartUnison.sh with the following contents:


#!/bin/bash

#Set UNISON environment variable
export UNISON=/mnt/disk4/appdata/unison

#Start Unison process in background (assuming I create a /mnt/disk4/bin directory and copy the Unison executable to it)
/mnt/disk4/bin/unison -socket 1111 &

2) When configuring the script in the Unraid web interface, schedule script to run at STARTUP of array.

The assumption here is that it runs just after all the discs are mounted, so it will find the Unison executable.

I am unsure if I should run the StartUnison.sh in background or foreground. (Linux is not good, but I am assuming that when the StartUnison.sh completes, it will not kill the actual unison prcess that is running in background with "&')  

 

Does that seem correct? 

 

Thank You!

Yes this is correct. You should run it in the background as there is no further interaction with the user.

Sorry for the confusing advice, but I was confused on unison's requirements, ie cli, background app, etc. 

Link to comment

Thank you for your help.

Everything WAS working great.  Now after my last reboot, I cannot start the array.  The GUI gets hung up on "Mounting Disks."

When I telnet to machine, all disks seem to be mounted correctly, and all user shares are set up.  But the array will not start, and the web interface becomes non-responsive.

 

Attached is the last log file if you have any advice-

 

Unison is pretty cool.  It allows me to sync certain directories on my Office PC to my unraid server.  The unraid server only requires a small executable running in background for the connection to my Office PC.  The Office PC has all the configuration files (which directories to sync, files to ignore, etc), and is run on demand. 

 

 

syslog.txt

Link to comment

Odd, must be some funny nature of the unison app when running in the background.

It probably has one of the really obscure shell/terminal disconnection which would prevent the script from really ending and thus prevent unRAID startup from proceeding properly.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...