0

Using Ubuntu 20.04 (focal) on WSL2 (Windows Subsystem for Linux) as a LAMP-stack/WordPress dev environment.

Since the required services do not automatically run when Windows 10 (main/parent OS) boots up, I created a /start file to call start on openssl, apache, and mysql and echo a confirmation statement. It looks just like this block of code.

    #!/bin/sh

service ssh start
service mysql start
service apache2 start

echo "System ready."

Now when I open a bash terminal, I just use sudo -s to switch to root and invoke /start. The output looks like this.

    focal@DESKTOP-6FLTF67:~$ sudo -s
    [sudo] password for focal:
    root@DESKTOP-6FLTF67:/home/focal# /start
    * Starting OpenBSD Secure Shell server sshd                                               [ OK ]
    * Starting MySQL database server mysqld                                                   [ OK ]
    * Starting Apache httpd web server apache2                                                                    
    * 
    System ready.
    root@DESKTOP-6FLTF67:/home/focal#

How do I make this work for service restart and shutdown purposes. Is it even allowable to configure for these commands? Because it matters not in what order I put the services, when I save a /restart or /stop file and run it, I keep getting this error.

    focal@DESKTOP-6FLTF67:~$ sudo -s
    root@DESKTOP-6FLTF67:/home/focal# /start
    * Starting OpenBSD Secure Shell server sshd                                                [ OK ]
    * Starting MySQL database server mysqld                                                    [ OK ]
    * Starting Apache httpd web server apache2                                                                    
    *
    System ready.
    *
    root@DESKTOP-6FLTF67:/home/focal# /stop
    bash: /stop: Permission denied
    *
    root@DESKTOP-6FLTF67:/home/focal# /restart
    bash: /restart: Permission denied
    *
    root@DESKTOP-6FLTF67:/home/focal# /stop
    bash: /stop: Permission denied

I have already tried all variations of shutdown down one service before/after the other, etc., and have double-checked the files against the working /start version, and they seem to be fine.

Can someone help me understand what I am missing? Thank you in advance!

killshot13
  • 219

1 Answers1

0

After reading a lengthier SO discussion that was sparked by a similar question, I finally understood the "why" behind the behavior I was experiencing.

So here is the answer.

After some pointed questions from @muru in the comments above, it dawned on me that although I had included #!/bin/sh at the top of each file, I had not run chmod +x $filename.sh to make the files (programs) fully executable.

Because of this, calling sh ./stop.sh or bash ./stop.sh worked fine, but I was attempting to call ./stop.sh directly, which did not.

Here is a before and after view of the solution.

Sample Script ~/run.sh

    #!/bin/sh

    service ssh start
    service mysql start
    service apache2 start

    echo "This version works too"

BEFORE (This is what I encountered originally.)

    ❯ sudo sh ./run.sh
     * Starting OpenBSD Secure Shell server sshd                   [ OK ]
     * Starting MySQL database server mysqld                       [ OK ]
    * Starting Apache httpd web server apache2                                                                               
    *
    This version works too

❯ sudo ./run.sh
sudo: ./run.sh: command not found

AFTER (After running sudo chmod +x run.sh)

    ❯ sudo ./run.sh
     * Starting OpenBSD Secure Shell server sshd                   [ OK ]
     * Starting MySQL database server mysqld                       [ OK ]
     * Starting Apache httpd web server apache2                                                          
    *
    This version works too

As you can see, I could only achieve the desired result after making the script executable with chmod +x run.sh.

NOTE: Additionally, I would advise the use of sudo to run scripts whenever possible instead of using root like I did in the original question. A safer option is to run these commands from within a user account that is part of the sudoers group, which helps limit security and user-error concerns that arise from using root directly.

killshot13
  • 219