I have been trying to do the quick start guide for Vue (CLI) but kept getting this error
Info There appears to be trouble with your network connection. Retrying...
Info There appears to be trouble with your network connection. Retrying...
Info There appears to be trouble with your network connection. Retrying...
and I see all answer in the same issue in this link
, but doesn't fix. ( OS: windows )
In my case, I had added a private npm repository into ~/.npmrc in the past, so yarn try to find the package in that repository.
And unfortunately the repository's no longer available, that makes yarn couldn't find the package.
Solution:
rm ~/.npmrc
In my case I've tried to build app inside Node Docker container. Adding option --network=host was the solution in my case.
docker build --network=host --progress=plain .
Can DC/OS run on in an offline environment?
After a successfull installation in my offline environemnt the login web screen would not open with the following message:
The server refused the connection.
I had to disable authentication in my cluster because Im running it in a private offline network.
Just add the following line in genconf/config.yaml before custom installation:
oatuh_enabled: 'false'
this way authentication needed.
https://dcos.io/docs/1.7/administration/opt-out/
I have been trying to get a local copy of Storm working, following the guide in the storm-starter repo, and this tutorial.
When trying to run a topology with mvn compile exec:java -Dstorm.topology=org.apache.storm.starter.ExclamationTopology, the output eventually continues looping & spamming:
28534 [Thread-9-SendThread(localhost:2000)] INFO o.a.s.s.o.a.z.ClientCnxn - Opening socket connection to server localhost/127.0.0.1:2000. Will not attempt to authenticate using SASL (unknown error)
28534 [Thread-9-SendThread(localhost:2000)] WARN o.a.s.s.o.a.z.ClientCnxn - Session 0x152f7728a6a0011 for server null, unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:1.8.0_45]
at Sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) ~[?:1.8.0_45]
at org.apache.storm.shade.org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361) ~[storm-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.shade.org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) [storm-core-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
It seems it is trying to connect to a local Zookeeper cluster, but I have not seen the dependency or install requirement for Zookeeper in the Storm docs or in this other tutorial.
Do I need to install Zookeeper and is this just missing from the docs? Perhaps I'm mistaken and it is looking for something else at port 2000 on my localhost? If not, what is going wrong in my local setup?
If you run locally and use LocalCluter you do not need to install Zookeeper.
If you run locally in pseudo-distributed mode (ie, start up Nimubs and Supervisor locally) and use StormSubmitter you do need to install Zookeeper locally.
i have done an hadoop cluster installation with cloudera manager. After this installation impala status has become bad.
I have the following error for master node:
Web Server Status
and this one for nodes with imapala daemon:
Impala Daemon Ready Check, Web Server Status
looking into logs i have found some errors:
The health test result for IMPALAD_WEB_METRIC_COLLECTION has become bad: The Cloudera Manager Agent got an unexpected response from this role's web server.
looking into cloudera-scm-agent.log there are those errors:
1261 Monitor-HostMonitor throttling_logger ERROR (29 skipped) Failed to collect NTP metrics
i tryed to install NTP (sudo apt-get install ntp) but after this installation HDFS, HIVE, YARN and others services goes bad, removing that only impala goes bad.
MainThread agent ERROR Failed to connect to previous supervisor.
Another error is this:
Monitor-GenericMonitor throttling_logger ERROR Error fetching metrics at 'http://nodo-1:50075/jmx'
i tried looking all hostnames and seems correct...
so, what is this problem? how can i solve it?
I also had problem with NTP, the problem still existed after installing NTP , but when I done sudo service ntp restart the error was fixed
We are trying to setup a build agent and every time we start it the log shows the following messages:
[2012-09-18 12:52:01,805] INFO - jetbrains.buildServer.AGENT - Starting agent shutdown sequence, reason: Restart agent, failed to download upgrade from server
[2012-09-18 12:52:01,821] INFO - jetbrains.buildServer.AGENT - Host configuration for downloading updates: HostConfiguration[host=http://localhost:8000]
[2012-09-18 12:52:01,821] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/teamcity-agent.xml ==> E:\buildAgent\temp\m8a1mAwTuLIngev3yRUMPUuaYWZFmMSh
[2012-09-18 12:52:01,849] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/agentSystemInfo.zip ==> E:\buildAgent\update\plugins\agentSystemInfo.zip
[2012-09-18 12:52:01,880] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/amazonEC2.zip ==> E:\buildAgent\update\plugins\amazonEC2.zip
[2012-09-18 12:52:01,921] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/ant.zip ==> E:\buildAgent\update\plugins\ant.zip
[2012-09-18 12:52:02,056] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/antPlugin.zip ==> E:\buildAgent\update\plugins\antPlugin.zip
[2012-09-18 12:52:02,078] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/assembly-info-patcher.zip ==> E:\buildAgent\update\plugins\assembly-info-patcher.zip
[2012-09-18 12:52:02,098] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/clearcase-agent.zip ==> E:\buildAgent\update\plugins\clearcase-agent.zip
[2012-09-18 12:52:02,106] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/commandLineRunner.jar ==> E:\buildAgent\update\plugins\commandLineRunner.jar
[2012-09-18 12:52:02,118] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/coveragePlugin.zip ==> E:\buildAgent\update\plugins\coveragePlugin.zip
[2012-09-18 12:52:02,151] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/crashDetector.zip ==> E:\buildAgent\update\plugins\crashDetector.zip
[2012-09-18 12:52:02,163] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/cvsAgent.zip ==> E:\buildAgent\update\plugins\cvsAgent.zip
[2012-09-18 12:52:02,183] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/dotCover.zip ==> E:\buildAgent\update\plugins\dotCover.zip
[2012-09-18 12:52:02,308] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/dotNetPlugin.zip ==> E:\buildAgent\update\plugins\dotNetPlugin.zip
[2012-09-18 12:52:03,830] INFO - agent.impl.AgentPortFileWriter - Delete agent runtime file from E:\buildAgent\logs\buildAgent.port
[2012-09-18 12:52:03,831] INFO - jetbrains.buildServer.AGENT - Unregistering from build server: 5
Has anyone seen anything like this before? We've looked at the server logs and aren't seeing anything on them to indicate what could be wrong.
I ran into the same issue. Both the build agent and the server are installed on Windows Server 2012.
I stopped the build agent service and deleted the logs from BuildAgent\logs and restarted the build agent service so I could see a fresh log.
upgrade.log showed me that the build agent received a call from the teamcity server to upgrade. The log also showed the following:
"Please check TeamCity build agent service user have enough permissions to stop and start the service."
Using the Local Security Policy, I granted the build agent service user "logon as a service" rights but this is not sufficient to start and stop a service. By default, only members of the Administrators group can start, stop, pause, resume or restart a service. After I added the build agent service user to the Administrator group and restarted the build agent service, the upgrade finished successfully and the agent connected again.
Alternatively, as described by BatteryBackupUnit and https://web.archive.org/web/20171019005501/http://windowsitpro.com/security/letting-user-start-and-stop-services-without-granting-user-administrator-privileges, it's possible to give the TeamCity Windows user account the start, stop and pause permissions on the TeamCity Build Agent service. The article says that something like
subinacl /service spooler /grant=contoso\cortana=top
will suffice.
Or, if you don't want to use a tool that Microsoft no longer makes available, then you can use Process Explorer, as described at https://superuser.com/a/315709/12337.
I had this problem when running the agent with systemd on Ubuntu 18.04. The agent exits with code 143 when upgrading and this is interpreted as an error. It needs to be added to the list of acceptable error codes with SuccessExitStatus=143 0
Here's the full configuration:
[Unit]
Description=TeamCity Build Agent
After=network.target
[Service]
Type=forking
RemainAfterExit=yes
PIDFile=/build-agent/logs/buildAgent.pid
ExecStart=/build-agent/bin/agent.sh start
ExecStop=/build-agent/bin/agent.sh stop
User=build
Group=build
Restart=on-failure
RestartSec=5s
# agent will exit with 143 during upgrade process
SuccessExitStatus=143 0
[Install]
WantedBy=multi-user.target
The TeamCity build agent can sometimes take a long time to upgrade. If you believe that the upgrading takes too long with no positive results do as follows:
Uninstall the build agent
Download the build agent pack from your server
Reinstall the agent
Upgrading process should go faster after this. If it does not help it is better to contact JetBrains tech support.
A really simple way of doing this if your enterprise security policy doesn't allow you to add users to the 'Administrators' group, but the user your logged on as does have elevated rights. Stop the service running, via the Services.msc and then open a command prompt (with elevated rights) in the agent bin directory and run
agent.bat start
Let the agent update with this user and then once it has finished and you can see it successfully registered in the Teamcity UI. Kill the processes and restart the Service.
If you're using a "jailed" build user like we are, you'll see "Please check TeamCity build agent service user have enough permissions to stop and start the service."
There are workarounds but no graceful solution to this. Here's why:
Workaround 1: "TCBuildAgent" service needs "jailed" needs start/stop service credential access assigned to it. SubinACL is your best tool for assigning this (lengthy but full discussion).
TeamCity removes "TCBuildAgent" and installs a new one, effectively eliminating the service credentials assigned to it. So, you must issue SubinACL grant access commands every time you upgrade. Clumsy and annoying
Workaround 2: Aforementioned tip of adding "jailed" to Administrators group is viable and permits a proper upgrade, though violates the concept of a "jailed" user.
After much fiddling with SubinACL, I've thrown in the towel and just temporarily add "jailed" to Administrators group for the upgrade process then remove it afterward.
I trust that Jetbrains isn't gonna do something awful and malicious with TCBuildAgent... not during upgrade, anyway ;)
I had a similar problem. helped me to reinstall the antivirus.
http://devnet.jetbrains.com/thread/440728
Stop the agent:
./agent.bat stop
Reinstall agent.
Start the agent:
./agent.bat start