I want to automatically start email tunnels and socks proxy at boot time. I have an /etc/init.d/email-tunnels script that invokes another script under my home directory. It won't work at boot time, it won't work if I execute sudo service email-tunnels start, but it does work if I just run it, sudo /etc/init.d/email-tunnels start. BTW, I have an identical setup on another machine (Debian 8), and it works like a charm on that one.

These are the details (of the Ubuntu 18 setup, the one that is not working):

[···]$ ls -lh /etc/init.d/email-tunnels 
-rwxr-xr-x 1 root root 602 Aug 28 10:21 /etc/init.d/email-tunnels

The contents is (including some debugging echos):

[···]$ cat /etc/init.d/email-tunnels 
#! /bin/sh

# Provides:     email_tunnels
# Required-Start:   $all
# Required-Stop:    $remote_fs $syslog
# Default-Start:    2 3
# Default-Stop:     0 1 6
# Short-Description:    E-mail and HTTP tunnels over SSH

echo "email-tunnels invoked at `date`" >> /tmp/email-tunnels.log

touch /var/lock/email-tunnels

case "$1" in
    echo "email-tunnels executing 'start' at `date`" >> /tmp/email-tunnels.log
    su -c "/home/cal/bin/email.sh &" cal
    echo "Usage: /etc/init/email-tunnels {start|stop}"
    exit 1

exit 0

And then, my script on my home directory:

[···]$ ls -lh /home/cal/bin/email.sh 
-rwxr-xr-x 1 cal cal 410 Aug 28 10:09 /home/cal/bin/email.sh

And its contents:

[···]$ cat /home/cal/bin/email.sh 

echo "email.sh executed at `date`" >> /tmp/email.log
sleep 30

while [ "1" == "1" ]
    echo "email.sh about to execute ssh at `date`" >> /tmp/email.log
    ssh -N -D5080 -Llocalhost:10110:xx.xx.xx.xx:110 -Llocalhost:10025:xx.xx.xx.xx:25 [email protected]
    sleep 120

The tunnels user on my target (server) machine does have the PK authentication properly configured, so that I can ssh-connect without any user interaction (without having to supply a password).

Any ideas why it's not working? From the debugging output, I see that the init.d script (email-tunnels) is executed (I see the output at /tmp/email-tunnels.log), but not the /home/cal/bin/email.sh --- when I manually run /etc/init.d/email-tunnels start, then I do see the /tmp/email.log debugging output, and for that matter the tunnels work after I ran it.

  • Is there a reason you're trying to do this is a daemon with /etc/init.d/ scripts rather than just having a cron job for that user scheduled to run @reboot?
    – DopeGhoti
    Aug 28, 2018 at 16:04
  • Then continue using Debian, and forget ubuntu. Aug 28, 2018 at 16:49
  • The @reboot feature seems a bit unreliable (e.g., unix.stackexchange.com/questions/109804/…). Plus, familiarity would also be a reason (I feel --- or maybe I should say felt --- more comfortable with handling the init.d scripts to do what needs to be done after a reboot)
    – Cal-linux
    Aug 28, 2018 at 16:50
  • @IporSircer --- hahaha, good point! I actually did adopt that position a couple of years ago; however, for desktop machines, I still haven't crossed the threshold of feeling comfortable enough with Debian. All of my non-GUI machines are now Debian. Notice, however, that we're not talking about the same underlying Debian version (my gateway machine at home, where the email-tunnels setup works, is Debian 8; Ubuntu 18, where I'm so far unable to make it work, is based on a Debain two versions later!)
    – Cal-linux
    Aug 28, 2018 at 16:54

1 Answer 1


You are using Ubuntu Linux, an operating system that has been a systemd operating system since 2016 and was an Upstart operating system for a decade before that, since 2006. van Smoorenburg rc scripts are not the way, especially for new stuff.

And especially in this case. This is almost a candidate for the House of Horror. On your system a generated service unit is running a process to interpret a script, that forks a process to run su (abusing that to drop privileges), that forks a process to run a shell, that forks a process to interpret another script, that runs an infinite loop Poor Man's Dæmon Supervisor that repeatedly forks ssh.

And all this just to do what a service manager can do anyway: run a specific program as a specific user and restart it every time that it exits.

Learn journalctl -b for reading the logs, and build upon this fairly simple basis:

# /etc/systemd/system/email_tunnels.service
Description=E-mail and HTTP tunnels over SSH

ExecStart=/usr/bin/ssh -N -D5080 -Llocalhost:10110:xx.xx.xx.xx:110 -Llocalhost:10025:xx.xx.xx.xx:25 [email protected]


Then you merely need to ensure that this service is run after your home directory, containing your SSH identity files, is available. Of course, with some setups this is only the case after you have logged in and your home directory has been auto-mounted, decrypted, and whatnot. In which case you might as well not set up a system-level service at all and instead run this as a user service under your per-user instance of systemd, which is started at your first login:

# /home/cal/.config/systemd/user/email_tunnels.service
Description=E-mail and HTTP tunnels over SSH

ExecStart=/usr/bin/ssh -N -D5080 -Llocalhost:10110:xx.xx.xx.xx:110 -Llocalhost:10025:xx.xx.xx.xx:25 [email protected]


Use the --user option to systemctl to control such a per-user service, of course.

Further reading

  • "Of course, with some setups this is only the case after you have logged in and your home directory has been auto-mounted, decrypted" .... Dwaarrrrggghh!!!! My home directory IS encrypted.... dammit, how could I forget/overlook that detail?!!!!!
    – Cal-linux
    Aug 28, 2018 at 19:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .