I want to run a python script in a tmux session on startup when launching my google cloud vm. I have searched around stack overflow and found this piece of code.
#! /bin/bash
sudo -H -u MyUser tmux new-session -d -s discord 'python3 MyFile.py'
I placed this in the meta data part of my vm where startup_scripts go but it doesn't launch when i start my vm. However when I run this code in the terminal after my vm has started it does exactly what I want it to do. What am I missing here?
After digging around for I while I found the problem. The command runs in the root directory so, before your piece of code, you have to add:
Add: cd home/username
Before your code.
Related
I have a WSL Ubuntu distro that I've set up so that when I login 4 services start working, including a web API that I can test via Swagger to verify it is up and working.
I'm at the point where what I want to do now is start WSL via a script - that is, launch my distro, have all of the services start, and do it from Python. The problem is I cannot even figure out the correct syntax to get WSL to start from PowerShell in a manner where my services start.
Side note: "services" != systemctl (or similar) calls, but just executing bash CLI commands from either my .bashrc or .profile at login.
I've put the commands to execute in .profile & .bashrc. I've configured it both for root execution and non-root user execution. I've taken the commands out of those 2 files and put it into a script in the Windows file system that I pass in on the start of wsl. And I've put that shell script in the WSL file system as well. Nothing seems to work, and sometimes the distro starts and then stops after about 30 seconds.
Some of the PS CLI commands I've tried:
Start-Job -ScriptBlock{ wsl -d distro -u root }
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c /root/bin/start.sh'
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c .\start.sh'
wsl -d distro -u root -- bash -i -l -c /root/bin/start.sh
wsl -d distro -u root -- bash -i -l -c .\start.sh
wsl -d distro -u root -- /root/bin/start.sh
Permutations of the above that I've tried: replace root with my default login, and turning all of the Start-Job bash options into a comma-separated list of single-quoted strings (Ex: 'bash', '-i', '-l', ... ). Nothing I launch from the CLI will allow me access to the web API that is supposed to be hosted on my distro.
Any advice on what to try next?
Not necessarily an answer here as much as troubleshooting tips which will hopefully lead to an answer:
First, most of the forms that you are using seem to be correct. The only ones that absolutely shouldn't work are those that attempt to run the script from the Windows filesystem.
Make sure that you have a shebang line starting your script. I'm assuming you do, but other readers may come across this as well. For the moment, try this form:
#!/usr/bin/env -S bash -li
That's going to have the same effect as the bash -li you tried -- It will source both both interactive startup files such as ~/.bashrc as well as login profiles such as ~/.bash_profile (and /etc/profile.d/*, etc.).
Note that preferably, you won't need the -li. Best practice would be to move anything necessary for the services over from the startup scripts to your start.sh script, and avoid parsing the profile and rc. I need to go update some of my answers, since I just realized I've been guilty of giving some potentially bad advice ...
Specifically, though, I'm wondering if your interactive Bash config has something truly, well, "interactive" in it that might be preventing the automatic running of the script itself. Again, best practice would be for ~/.bashrc to only hold configuration that is needed for interactive shell sessions.
Make sure the script is set as executable (chmod +x start.sh). Again, I'm assuming this is the case for you.
With a shebang line and an executable script, use something like:
wsl -d distro -u root -e /root/bin/start.sh
The -e tells WSL to launch the script directly. Since it has a shebang line, it will be parsed by Bash. Most of the other forms you use above actually run Bash twice - Once when launching WSL and another when it finds the shebang line in the script.
Try some basic troubleshooting for your script like:
Add set -x to the top (right under the shebang line) to turn on script debugging.
Add a ps -efH at the end to show the processes that are running when the script completes
If needed, resort to quick-and-dirty echo statements to show where things have progressed in the script.
I'm hopeful that the above will at least show you the problem, but if not, add the debugging info that you gain from this to your question, and we can troubleshoot further.
I'm experiencing this really weird issue which I just can't understand why it is happening. When I execute following command from my shell manually it works.
sudo -u some-user echo "$SSH_KEY" | /home/some-user/.ssh/authorized_keys
however from a bash script it fails with a message we don't have any permissions.
#!/bin/bash
sudo -u some-user echo "$SSH_KEY" | /home/some-user/.ssh/authorized_keys
Is there any bash option to configure, or can someone explain this behavior?
It looks a bit like a bash security thingy for non interactive terminals or something like that, but I lost my creativity to google for the solution.
I'm running Ubuntu 16.04.
After hours of investigation it seems sudo commands where not executed because of the password prompt which does not occur from the script.
The solution was to first run a sudo command before runnning the script or just runnning the whole script as sudo so you can enter the password one time and the other sudo commands are running without password prompts.
Ok everyone, here is an issue which bugged me for quite some time now:
I am trying to run a bash script, which stores certain values in variables, and then starts another command in a detached session, so that the script can continue running because the command takes ages to finish. That's all fine and nice, but the problem is that the command which should be run in the detached session contains variables. This is not a problem when using screen as the "session manager" (or whatever you want to call a program doing session management):
read -p "Session name:" sessionname
read -p "Filename:" filename
screen -S "$sessionname" -d -m nano "$filename"
works fine, opening nano in the detached screen as expected. But when i re-attach to the session and close it, my terminal is cleared and sometinmes some of the text from the file is barfed right before my cursor. I realized that this is an issue with how screen works, so i decided to switch to tmux, but now a whole new realm of prblems opens:
tmux new-session -d -s "$sessionname" nano "$filename"
works fine on cygwin, but on my raspberry 2b running raspbian jessie it throws this error:
usage: new-session [-AdDp] [-c start-directory] [-F format] [-n window-name] [-s session-name] [-t tar
get-session] [-x with] [-y height] [command]
and trying tmux ls afterwards to see if anything started gives me this on the raspberry:
failed to connect to server: No such file or directory
while on cygwin, if no sessions are running, it gives me this:
no server running on /tmp/tmux-197609/default
How can it be that tmux on two different plattforms behaves conmpletely different? Have i installed it wrong on the raspberry (sudo apt-get install tmux) ?
I am all out of ideas what might be the problem here, so any help is greatly appreciated. (Sorry for confused spelling & grammar, non-native english speaker here)
Running postgreSQL 9.4.5_2 currently
I have tried
pg_ctl stop -W -t 1 -s -D /usr/local/var/postgres -m f
Normally no news is good news but after I will run
pg_ctl status -D /usr/local/var/postgres
and get pg_ctl: server is running (PID: 536)
I have also tried
pg_ctl restart -w -D /usr/local/var/postgres -c -m i
Response message is:
waiting for server to shut down.......................... failed
pg_ctl: server does not shut down
I've also checked my /Library/LaunchDaemons/ to see why the service is starting at login but no luck so far. Anyone have any ideas on where I should check next? Force quit in the activity monitor also isn't helping me any.
Sadly none of the previous answers help me, it worked for me with:
brew services stop postgresql
Cheers
I tried various options; finally, the below command worked.
sudo -u postgres ./pg_ctl -D /your/data/directory/path stop
example
sudo -u postgres ./pg_ctl -D /Library/PostgreSQL/11/data stop
As per the comments, the recommended command is without the ./ when calling pg_ctl:
sudo -u postgres pg_ctl -D /Library/PostgreSQL/11/data stop
Tried sudo and su but no such luck.
Just found this gui
https://github.com/MaccaTech/postgresql-mac-preferences
If anyone can help with the terminal commands that would be very much appreciated, but till then the gui will get the job done.
Had the same issue, I had installed postgres locally and wanted to wrap in a docker container instead.
I solved it pretty radically by 1) uninstalling postgres 2) kill the leftover process on postgres port. If you don't un-install the process restarts and grabs the port again - look at your Brewfile form brew bundle dump to check for a restart_service: true flag.
I reasoned that, as I am using containers, I should not need the local one anyway, but !! attention this will remove postgres from your system.
brew uninstall postgres
...
lsof -i :5432 # this to find the PID for the process
kill - 9 <the PID you found at previous command>
Note: if you still want to used psql you can brew install libpq, and add psql to your PATH (the command output shows you what to add to your .zshrc, or similar)
you can stop the server using this command
{pg_ctl -D /usr/local/var/postgres stop -s -m fast}
Adding onto the solutions already stated :
if you decide to use the pg_ctl command, ensure that you are executing the command as a user with the permissions to access the databases/database server.
this means :
the current logged in user on your terminal should have those permissions
or
first run :
$ sudo su <name_of_database_user>
pg_ctl -D /Library/PostgreSQL/<version_here>/data/ stop
the same goes for the start command.
credit : https://gist.github.com/kingbin/9435292
(essentially hosted a file with the commands on github, saved me some time :^) )
I had a stray docker container running Postgres that I had forgotten about.
I am getting this error while cloning the site on aegir
Unknown option: --profile. See drush help provision-backup for available >options. To suppress this error, add the option --strict=0. [2.39 sec, 21.19 MB]
I am using aegir3 on ubuntu 14.04.4. Can anyone please help me solve this. I have searched on web but there is no solution regarding this issue. This issue also occurs while migrating.
you might find more Aegir users at the new community support forum
http://ask.aegir.support/
I had a similar issue and found a solution there
I found that debugging Aegir issues was a lot easier if you executed the Drush commands directly.
You can find the command by looking through the Log Messages keeping an eye out for entries like
Backend invoke: /usr/bin/php -d magic_quotes_gpc=Off -d magic_quotes_runti... (Expand)
Below entries like the above you will find the command that was executed, expand that by clicking the (Expand) and copy the command (I found sometimes the expand did not work, in cases like this I just use chrome tools to look at the source and copy it)
/usr/bin/php -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off /var/aegir/.composer/vendor/drush/drush/drush.php --php=/usr/bin/php --php-options=' -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off' --backend=2 --yes #centosintranet provision-install-backend --client_email='this.email#is.invalid' 2>&1
All you need to do now is run this as the Aegir user via bash. If you use the apt-get package to install Aegir you should be able to open a terminal and enter
sudo su - aegir -s /bin/bash
You will be prompted for your password, after entering it you will have a bash shell as the Aegir user. Paste in the above drush command and press enter.
Watch it execute, I found it easier to work out what was going on by removing the --backend=2 option. If you still can't see what the issue is try adding -vvv or --debug to the drush command.
Using this method I have solves all issues I have run into thus far when Aegir falls over.