Just for a trial I got my hands dirty installing Meteor 1.6 using Chocolatey.
When I ran the command 'choco install meteor', after little time, I receive error below
Downloading meteor 64 bit
from 'https://packages.meteor.com/bootstrap-link?arch=os.windows.x86_64'
Progress: 48% - Saving 83.27 MB of 171.74 MB C
hocolatey timed out waiting for the command to finish. The timeout
specified (or the default value) was '2700' seconds. Perhaps try a
higher `--execution-timeout`? See `choco -h` for details.
The install of meteor was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\meteor\tools\chocolateyinstal
l.ps1'.
See log for details.
Chocolatey installed 1/2 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures
- meteor (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\meteo
r\tools\chocolateyinstall.ps1'.
See log for details.
By default, Chocolatey has a command timeout of 45 minutes (2700 seconds) as documented here:
https://chocolatey.org/docs/chocolatey-configuration#general
Is the download of the meteor installer taking longer than this?
If so, you can change the value using a command similar to this:
choco config set --name <nameFromBelow> --value <value>
i.e. in your case (again, as an example):
choco config set --name commandExecutionTimeoutSeconds --value 5400
Or, if you only want this timeout to apply to a single command, you can try:
choco install meteor --execution-timeout 5400
As mentioned in the error output.
Related
brew
brew install not work. this is the log.
% brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.4.13.mojave.bottle.tar.gz
Already downloaded: /Users/shingo/Library/Caches/Homebrew/downloads/d56104142081a8230646ac3f245adf2414e515cd5f2aeeb0637614e9966e882c--mariadb-10.4.13.mojave.bottle.tar.gz
==> Pouring mariadb-10.4.13.mojave.bottle.tar.gz
==> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
Last 15 lines from /Users/shingo/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
MySQL is configured to only allow connections from localhost by default
To start mariadb:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.4.13: 744 files, 169.9MB
I have tried to execute mysql_install_db
I have tried to execute mysql_install_db without brew. this is the log.
The brew displays only the last 15 lines, so I can't help it.
% /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
chown: /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool: Operation not permitted
Couldn't set an owner to '/usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2020-05-29 22:13:03 0 [Note] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld (mysqld 10.4.13-MariaDB) starting as process 45440 ...
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: option '--innodb-large-prefix' requires an argument
2020-05-29 22:13:03 0 [ERROR] Parsing options for plugin 'InnoDB' failed.
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-29 22:13:03 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.4.13/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
I noticed that the system can not chown for auth_pam_tool because Operation not permitted.
auth_pam_tool permission
this is my permission the directory.
% ls -l /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
-r-xr-xr-x 1 shingo staff 13608 5 10 04:28 /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
How to fix Operation not permitted?
Or is there any other reason why it cannot be installed?
Self resolved.
Anyway I gave it try start
Even though the installation was not successful, anyway I gave it try % mysql.server start.
A error log file was created.
A error log file was created by starting mysql server.
the error log shows:
2020-05-30 8:47:10 0 [Warning] InnoDB: innodb_open_files 300 should not be greater than the open_files_limit 256
2020-05-30 8:47:10 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-30 8:47:10 0 [ERROR] Aborting
An unknown value in the mysqlx-bind-address seems to be causing the error.
How to fix unknown variable
I found
the same error question. This question discussed a my.conf file.
~/.my.conf did not exist on my mac
/etc/my.conf did not exist on my mac
this question teach me the my.conf location.
Finally I found my.conf in /usr/local/etc/my.cnf.Certainly the settings for mysqlx-bind-address were written in my.conf.
So rm /usr/local/etc/my.cnf, then brew reinstall SUCCESS!.
The permission was irrelevant at all.
this work for me:
rm /opt/homebrew/etc/my.cnf
How to auto restart of mariadb goes down when it get killed.
As of now i am using crontab which doesnot help as its checking every 1min and not every second is there any solution related to systemd?
When installing from RPM or .deb packages on distributions that have switched to systemd a service is set up by default already.
If you are installing from a generic linux binarytarball a mariadb.service file is included in the archive, but needs to be installed manually.
See https://mariadb.com/kb/en/library/systemd/ for details.
Or you could still use the classic mysqld_safe wrapper script, which starts mysqld for you and will restart it when "death of a child" signals are received, unless mysqld has been shut down gracefully with "mysqladmin shutdown".
See: https://mariadb.com/kb/en/library/mysqld_safe/
I am installing ICp 2.1.0.1 and I received an error at the TASK
[master: Waiting for MariaDB service to start] msg: The MariaDB
component failed to start.
After this msg the installation completed with failed status.
We are installing ICp with 3 Masters, 3 Proxies and 2 Workers. We have 1 IP for VIP master and 1 for VIP proxy.
I tried to install multiple times and all installations got the same error.
For prior issues with that error, the correct db admin password was not used. So check the db user and password to resolve issue.
Would you validate whether each master host was able to access port 3306 on the other hosts?
If you run with .. install -vv | tee -a install-log.txt, do you get additional details as well?
The error was solved by following the steps below.
Check whether kubelet is running:
Log in to your master node.
Run the following command to check kubelet status:
systemctl status kubelet
If kubelet is not running, run the following command to get the logs:
journalctl -u kubelet &> kubelet.log
We found the error in the kubelet.log log:
Error: failed to run Kubelet: Running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false.
We found this troubleshoot in this link, and the solution at the ICP issue 4651.
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_2.1.0/troubleshoot/etcd_fails.html
https://github.ibm.com/IBMPrivateCloud/roadmap/issues/4651
How can I stop the http server, downloaded using 'npm install http-server" comand in terminal (console) and launched then?
Simply Ctrl+C, if you read the output after you launch it, you should see:
Starting up http-server, serving xxx
Available on:
http://<some ip>:<some port>
Hit CTRL-C to stop the server
Its built on node so Kill the node process for stopping it if it stuck. You can find all the node process ids and see what I'd your server have and kill that.
I have a new version of R installed on an aws-machine (which always come with an old version for some reason and it's near impossible to just have yum or apt-get to work). I want rstudio to point to this new version which I've built from source without throwing the old version away. I therefore go to /etc/rstudio/rserver.conf (documentation) and change the contents to:
# Server Configuration File
rsession-which-r=/root/R-3.2.1/bin/R
I can confirm that at this location a new version of R is installed but then I get an error after rstudio-server restarts.
root#ip-172-31-40-49 rstudio]$ rstudio-server restart
initctl: Unknown instance:
What am I to do?
Below worked for me:
1) check the process that used 8787
sudo fuser 8787/tcp
2) with the -k option to kill all process.
sudo fuser -k 8787/tcp
3) Start RStudio Server
sudo rstudio-server start
The solution above is provided here by Leon Zhang.
The first thing to do is to check your configuration with:
rstudio-server verify-installation
a number of times when updating R or RStudio I have run into the same error as you have and get the following error message.
-bash-4.1$ sudo rstudio-server verify-installation
29 Sep 2015 18:24:11 [rserver] ERROR system error 98 (Address already in use); OCCURRED AT: rstudio::core::Error rstudio::core::http::initTcpIpAcceptor(rstudio::core::http::SocketAcceptorService<boost::asio::ip::tcp>&, const std::string&, const std::string&) /root/rstudio/src/cpp/core/include/core/http/TcpIpSocketUtils.hpp:103; LOGGED FROM: int main(int, char* const*) /root/rstudio/src/cpp/server/ServerMain.cpp:436
rstudio-server start/running, process 48632
Although I have never been able to figure out the cause, I can suggest the following workaround:
1. change the port /etc/rstudio/rserver.conf for example from 8787 to 8788
2. open the new ports in your firewall settings. (allow access to the new port in /etc/sysconfig/iptables)
3. update your firewall: sudo /sbin/service iptables restart
4. restart Rstudio server: sudo rstudio-server restart
This has worked for me each of the ~4-5 times this has happened. Although I am not 100% sure this can help with your use case, it may. As an alternative, if you can use containers in your AWS setup, you may be interested in a great off-the shelf docker image with the latest R/Rstudio.
It happened for me on my Cento-7.x machine while I upgraded from old RStudio server to the new version. Rebooting the machine seems to have fixed the problem.