3

I have a tmux triggering script as mentioned below, running on Raspbian Wheezy 7.10:

  • Step 1

    #!/bin/bash
    # this script is called "sess"
    
    tmux new-session -d -s sess1 'sudo /home/pi/bin/myscript.py'
    exit 0
    

I have checked the running script as follows :

  • first by running the python script sudo /home/pi/bin/myscript.py and then by typing the tmux command as mentioned above tmux new-session -d -s sess1 'sudo /home/pi/bin/myscript.py'. Both the times the script runs.

Since if a User can type and run this scripts, it is a safe assumption that the complete thing can be written as a bash script. Hence the above mentioned script 'sess'

  • Step 2

I have give this file executing rights through chmod +x /home/pi/bin/sess

  • Step 3

I have also tried to run the script using rc.local as the following:

# in the rc.local file 

/home/pi/bin/sess &
exit 0

The rc.local file gets triggered for a fact since I set WLAN parameter on boot for my Pi to join an Ad-Hoc Network.

I can clearly verify this since I can ssh into my Pi.

Observations:

Upon reboot the script is not triggered. This can be verified through the tmux ls command which says Connection to Server Failed. I have also verified using sudo tmux ls incase if the superuser has the tmux session but the Output is same.

  • Step 4

I tried running the script in crontab using:

sudo crontab -u pi -e

## inside the crontab

@reboot /home/pi/bin/sess &

I also tried creating a cron job for the superuser

sudo crontab -e

@reboot /home/pi/bin/sess &

Observations:

Upon reboot the script is not executed.

  • Step 5

I created a sub-shell in the rc.local to capture any activity of the script being triggered

# in the rc.local file
(/home/pi/bin/sess &) > /tmp/tmux.log

Observations

upon reboot and cat /tmp/tmux.log there is nothing inside the file. The file tmux.log does get created though

Inferences

Ironically, if do something like sudo /etc/rc.local or sudo ~/bin/sess while i am logged in the script gets triggered perfectly since I can actually attach the session using sudo tmux a and also see the listing sudo tmux ls

But since it cannot run on boot time the purpose is useless if not triggered on boot.

I have also checked the environment variables $PATH which actually does show /home/pi/bin in it.

I have also tried using the complete path to tmux in all my scripts since if the environment variables might not be sorted. But no Luck

$ which tmux
$ /usr/bin/tmux

Ironically, If I follow such a step on my Ubuntu 14.04 LTS laptop the script gets triggered through my rc.local file

Further options

  1. Maybe try an init.d/ daemon-script but not sure if an rc.local and a crontab can't handle this then maybe a daemon also wont

  2. I have no idea if a ~/.tmux.conf is any good.

  • Please edit your question and add your operating system. Is the rc.local even run? What happens if you add echo foo > /tmp/local.log or similar? Is the /tmp/local.log file created? – terdon Jul 7 '16 at 16:17
  • Thanks for the edit, but please don't add "Edit" to your questions, just do the edit in such a way that someone reading it for the first time would understand it. Think of this site like a wiki, there's no need to highlight edits, just make sure the question has all necessary information. Did you check whether commands in rc.local in general are run? (although they should be, but you may as well make sure) – terdon Jul 7 '16 at 16:28
  • Sorry for that. I will get back to you with the tests. I think I will update the OS version to Raspbian Jesse and see if it was some flaw in the OS. rc.local gets triggered because I have other parameters I set upon reboot which are triggered perfectly. – Shan-Desai Jul 7 '16 at 16:30
  • No need to apologize, I know the rules here are hard to get used to :) OK, if other things are running then that's not the issue. Not surprised, really. The other thing to try is to run the command directly in the rc.local file, not with a function. Just keep things as simple as possible until you figure out what's going on. – terdon Jul 7 '16 at 16:33
  • @terdon I tried the simple method and even exported the PATH but it still doesnt work? do you mind if I share you a gist of all the steps I have done so maybe you can get more idea about what exactly I want to do? – Shan-Desai Jul 7 '16 at 18:16
2

The most optimized solution to troubleshoot any detached script using tmux will require you to use the following option within your triggering script:

#!/bin/bash
# this script is called "sess"

tmux new-session -d -s sess1

# this statement is a life-saver for tmux detached sessions
tmux set-option -t sess1 set-remain-on-exit on

# In my case running the script in a new window worked
tmux new-window -d -n 'nameofWindow' -t sess1:1 'sudo /home/pi/bin/script.py'

exit 0

Now the following script was called from the rc.local and the Pi was rebooted. Eventually on reboot when you attach the session using sudo tmux a Once gets a tmux session with 2 windows

  1. Initial one is just an empty session triggered due to tmux new-session -d -s sess1

  2. and the another one from the tmux new-window command which can be opened using CTRL+B + 1 since it was mentioned as sess1:1 (note: Hot keys may vary for user, the default tmux hotkey (bindkeys) are CTRL+B)

Inference

If the script ends with an error, the Window will show you where the error was in my case errors in my Python script and at the Bottom it will show Pane is Dead. Hence due to errors in the script the tmux session was exited without giving any relevant log(feedback) hence no output was logged in the above mentioned /tmp/tmux.log

Hence it is always recommended using the set-remain-on-exit on when running scripts with tmux in case if there are faults in the the script in detached mode

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.