Terminal commands running extremely slow - performance

I am currently having an issue where certain terminal commands are running extremely slowly.
Some example commands include: kubectl or brew
Currently time kubectl version takes 14s and time brew -v takes around 44s.
I've looked at other threads and they said to check what $PATH is set to, and it seems like mine is set correctly already:
echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/hardy/.fzf/bin
I have also tested with set -x to see exactly what is the delay. When I run kubectl or brew with set -x on, I am able to see that it stalls for an extremely long period of time after the command is run. It stalls for about 40s here:
brew -v
+ brew -v
Both brew and kubectl are located in /usr/local/bin. There are other commands that are located in /usr/local/bin that are not running extremely slow. Just a select few are running slow I believe.
Do you guys have any idea what the issue is or how to further debug this?

Related

Can't find nix-env or nix-build on MacOS Catalina

I can't find nix-env, nix-build, nix-shell etc. on MacOS Catalina.
I installed with:
sh <(curl https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume
and was able to run them yesterday. I restarted my computer and can no longer find them. find / -name nix-env | grep nix-env shows nothing.
I tried installing again with the same command (sh <(curl https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume) but this time it exists immediately with 0 status code.
I suspect I need to do something to mount a virtual drive.
You should follow Notes on the recommended approach.
It looks like the volume is not mounted (check /etc/fstab state with vifs as described in documentation).
Use the Disk Utility UI to remove the nix volume (sudo rm -rf /nix won't work).
Then run the script again and cross fingers your fingers this time: sh <(curl https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume
While Nix (amongst others) installs with bash newer MacOS do use zsh instead of bash.
So you need to update your .zshrc to source this command from bash, too.
In your terminal start editing with:
sudo nano ~/.zshrc
and add:
source ~/.nix-profile/etc/profile.d/nix.sh
Reload and test with
source ~/.zshrc; nix --version

Why can I not use the command history in minikube ssh

I have a minikube K8s 1 node cluster on my Windows 10 pc. I can SSH into this cluster using minikube ssh.
The problem that I am experiencing is that I can't use the arrow keys to bring back the previous command. I did some looking around and diagnostics:
set -o | grep history gave history on
echo $HISTFILE gave /home/docker/.bash_history. This is indeed in the home folder of the user and the file was present after exiting and executing minikube ssh again
echo $HISTSIZE and echo $HISTFILESIZE both gave 500
echo $SHELL gave /bin/bash
All these things tell me that command history should be enabled, but it doesn't seem to be the case.
I tried using both Powershell and cmd to run minikube ssh, both with and without Windows Terminal.
Both PowerShell and cmd themselves have a working command history, but once SSHing using minikube, the history in the bash shell doesn't work.
Does anyone know how to get the command history to work after executing minikube shh?
Edit:
I have tried minikube ssh --native-ssh=false, but this didn't change anything.
It seems to be a problem with the SSH client you are using. You can try with the --native-ssh=false option:
minikube ssh --native-ssh=false
You can also try with different alternatives or with something like the ssh version that comes with Cygwin.
There is already an unsolved issue related to this. (Feel free to update)
✌️

Mac mojave - sudo uid reset

long story short,
1.my PATH got messed up so the zsh throws an "command not found" error in the terminal
tried to uninstall and reinstall the homebrew to see if that does anything - it did not.
now sudo throws me an error
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
the reason why(well my guess) sudo throws this error that is that while
I manually delete the files as the homebrew recommended, I must have deleted or done something in
/usr/local so now sudo uid is not 0 anymore.
I have tried
mount -uw /
chown 0 /private/etc/sudoers
exit
and these instructions
A. https://apple.stackexchange.com/questions/157772/sudo-etc-sudoers-is-owned-by-uid-501-should-be-0?fbclid=IwAR0HPT64TzzkuKs1ymsqb2l8HThXqRpGifX_QAdzrK5z5XgecavTzWiQVh0
B. https://forums.macrumors.com/threads/not-able-to-use-sudo-commands-in-terminal.2101126/?fbclid=IwAR3BL-Sajkrsp02i5MCAKM7DZ0C83xUFOg9pzRhpG1hLrzpk9FbnDbbjoaM
but none of them worked.
What is the last thing I can do?
If I delete the drive and re-install it(disk utility), will it also change the sudo problem?
That is, of course, the last thing I would like to do. but I am considering it now.
Any thoughts?
HELP!
After digging everywhere, I found the answer here,
My sudo command not working
One of the main issues I had was that the sudo uid set to 501 instead of 0.
#GordonDavisson had a solution using "Script Editor" and run the code
do shell script "chown root:wheel /etc/sudoers; chmod 440 /etc/sudoers; chmod -N /etc/sudoers" with administrator privileges
as he mentioned.
This successfully changed my root. I checked it by running
ls -l /etc/sudoers
in the terminal.
After this, I could re-install the homebrew.
Though I encounter unusual steps, where homebrew was running,
it asked me several times to enter the password for different stages
which did not happen before.
But after re-installing the Homebrew, I changed my $PATH
export PATH=$PATH:/usr/local/git/bin:/usr/local/bin
and now I can live again!

Cannot clone an aegir site

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.

Monit + RVM + Thin on OSX / Linux

After trying for hours (and also trying God and Bluepill) I decided to ask my question here because I am completely clueless how to solve this issue.
I have a Rails app. I want to use Thin as my app server. I want to use Monit to monitor my Thin instances. I use RVM to manage my Ruby versions as my local user.
I have the following monit file set up that would assumably do what I want it to do, but doesn't:
check process thin-81
with pidfile /Users/Michael/Desktop/myapp/tmp/pids/thin.81.pid
start program = "/Users/Michael/.rvm/gems/ruby-1.9.2-p180/bin/thin start -c /Users/Michael/Desktop/myapp -e production -p 81 -d -P tmp/pids/thin.81.pid"
stop program = "/Users/Michael/.rvm/gems/ruby-1.9.2-p180/bin/thin stop -c /Users/Michael/Desktop/myapp -P tmp/pids/thin.81.pid"
if totalmem is greater than 150.0 MB for 2 cycles then restart
If I simply copy/paste the start program in to the command line (outside of Monit) it works. Same goes for the stop program to afterwards stop the Thin instance. Running it via Monit however, does not seem to work.
Running it in -v verbose mode yields the following:
monit: pidfile '/Users/Michael/Desktop/myapp/tmp/pids/thin.81.pid' does not exist
Which leads me to believe that Thin never initializes. Does Monit run as root or something? Cause if it does then it obviously won't have the correct gems installed since I'm using RVM and not the "system" Ruby. I am currently on OSX (but will deploy to Linux eventually) - does anyone know what the cause of this might be? And if Monit is run via root, how could I make it use RVM regardless? Or could I tell Monit to execute the start/stop programs as Michael:staff (I assume it would be on OSX?)
Any help is much appreciated!
monit clears out the environment and also doesn't run a shell for your command (let alone an interactive one). I find I have to do something like:
/usr/bin/bash -c 'export rvm_path=/home/foo/.rvm; . $rvm_path/scripts/rvm; cd my_ruby_app_path; $rvm_path/bin/rvm rvmrc load; ./my_ruby_app'
as the monit start command.
another option which I found in the RVM google group is as follows:
start program = "/bin/su - myuser -c '/path/to/myscript.rb start' "
su - user runs the user's shell as a login shell, so if the
user's shell is bash, it will cause ~/.bash_profile to be run so the
environment variables should be the same as just after that user
logged in.
We need the path for su, otherwise, monitrc would not able to find the su executable.
A better way would be to use an RVM wrapper to create a custom executable for thin. It will create the correct environment variables to use the right ruby and gems, and then launch thin. Read more about it using it with god here : https://rvm.io/integration/god/. It should work the same with monit
To create the wrapper:
rvm wrapper ruby#gemset bootup thin
Then change start program and stop program to use the executable you just created.

Resources