Everything started with me trying to deploy MQTT Mouqette and MQTT Bridge on my GG Core.
I suddenly see that my deployment doesnt complete for hours. It stayed in progress over night.
Next day I restart my gg service on my linux box and redeploy. Everything works. Now I have a config change in the MQQT Bridge, so I do a deployement revision and now im stuck. Even a restart on my gg service is not fixing it.
My greengrass.log file shows this in an infinite loop.
2022-04-12T17:53:47.678Z [WARN] (Thread-5) com.aws.greengrass.mqttclient.AwsIotMqttClient: Connection interrupted. {clientId=Instrument-Orchestrator-Bologna, error=The connection was closed unexpectedly.}
2022-04-12T17:53:48.031Z [INFO] (Thread-5) com.aws.greengrass.mqttclient.AwsIotMqttClient: Connection resumed. {clientId=Instrument-Orchestrator-Bologna, sessionPresent=true}
2022-04-12T17:53:48.031Z [INFO] (pool-2-thread-25) com.aws.greengrass.certificatemanager.certificate.CISShadowMonitor: Publishing to get shadow topic. {}
2022-04-12T17:53:48.081Z [WARN] (Thread-5) com.aws.greengrass.mqttclient.AwsIotMqttClient: Connection interrupted. {clientId=Instrument-Orchestrator-Bologna, error=The connection was closed unexpectedly.}
2022-04-12T17:53:48.462Z [INFO] (Thread-5) com.aws.greengrass.mqttclient.AwsIotMqttClient: Connection resumed. {clientId=Instrument-Orchestrator-Bologna, sessionPresent=true}
2022-04-12T17:53:48.462Z [INFO] (pool-2-thread-23) com.aws.greengrass.certificatemanager.certificate.CISShadowMonitor: Publishing to get shadow topic. {}
2022-04-12T17:53:48.512Z [WARN] (Thread-5) com.aws.greengrass.mqttclient.AwsIotMqttClient: Connection interrupted. {clientId=Instrument-Orchestrator-Bologna, error=The connection was closed unexpectedly.}
My Core Device in the AWS Console never shows the correct components.
My deployment is always in progress since then, but locally if Im checking with the greengrass-cli all my deployments seem fine.
What did I mess up? I get we have a shadow update issue. But I dont know how to fix it.
Related
I have a cluster with 2 galera nodes and 1 arbitrator.
My node 1 crashed I don't understand why..
Here is the log of the node 1.
It seems that it is a problem with the pthread library.
Also every requests are proxied by 2 HAProxy.
2023-01-03 12:08:55 0 [Warning] WSREP: Handshake failed: peer did not return a certificate
2023-01-03 12:08:55 0 [Warning] WSREP: Handshake failed: peer did not return a certificate
2023-01-03 12:08:56 0 [Warning] WSREP: Handshake failed: http request
terminate called after throwing an instance of 'boost::wrapexcept<std::system_error>'
what(): remote_endpoint: Transport endpoint is not connected
230103 12:08:56 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.5.13-MariaDB-1:10.5.13+maria~focal
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=101
max_threads=102
thread_count=106
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 760333 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
mariadbd(my_print_stacktrace+0x32)[0x55b1b67f7e42]
Printing to addr2line failed
mariadbd(handle_fatal_signal+0x485)[0x55b1b62479a5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7ff88ea983c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7ff88e59e18b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7ff88e57d859]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0x9e911)[0x7ff88e939911]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa38c)[0x7ff88e94538c]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa3f7)[0x7ff88e9453f7]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa6a9)[0x7ff88e9456a9]
/usr/lib/galera/libgalera_smm.so(+0x448ad)[0x7ff884b5e8ad]
/usr/lib/galera/libgalera_smm.so(+0x1fc315)[0x7ff884d16315]
/usr/lib/galera/libgalera_smm.so(+0x1ff7eb)[0x7ff884d197eb]
/usr/lib/galera/libgalera_smm.so(+0x1ffc28)[0x7ff884d19c28]
/usr/lib/galera/libgalera_smm.so(+0x2065b6)[0x7ff884d205b6]
/usr/lib/galera/libgalera_smm.so(+0x1f81f3)[0x7ff884d121f3]
/usr/lib/galera/libgalera_smm.so(+0x1e6f04)[0x7ff884d00f04]
/usr/lib/galera/libgalera_smm.so(+0x103438)[0x7ff884c1d438]
/usr/lib/galera/libgalera_smm.so(+0xe8eea)[0x7ff884c02eea]
/usr/lib/galera/libgalera_smm.so(+0xe9a8d)[0x7ff884c03a8d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7ff88ea8c609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7ff88e67a293]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Fatal signal 11 while backtracing
PS: if you want more data ask me :)
OK it seems that 2 simultaneous scans of OpenVAS crashes the node.
I tried with version 10.5.13 and 10.5.16 -> crash.
Solution: Upgrade to 10.5.17 at least.
When I try to look up for this kind of problem, most are because they were using a proxy, but I don't. I get this error on my git bash:
$ yarn create next-app firstapp
yarn create v1.22.19
[1/4] Resolving packages...
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...
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "https://registry.yarnpkg.com/create-next-app: tunneling socket could not be established, cause=getaddrinfo ENOTFOUND 8889".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\username\\AppData\\Local\\Yarn\\Data\\global\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/create for documentation about this command.
I'm following the guide on nextjs.org. I thought it was due to my bad connection, but when I try it another time, I still get the same error.
My Node.js is at v14.17.5.
I have installed on Fedora 35 jfrog-artifactory-oss (v7.31.11-73111900.x86_64) and enabled it as a system service to start at boot. But whenever I boot up my OS, the server never starts properly. I will always need to kill the PID of the active running Artifactory process. If I then do sudo service artifactory restart it will bring up the server cleanly and everything is good. How can I avoid having to do this little dance? Is there something about OS boot up that is causing Artifactory to get thrown off?
I have looked at console.log when the server is not running properly after bootup, I see some logs like:
2022-01-27T08:35:38.383Z [shell] [INFO] [] [artifactoryManage.sh:69] [main] - Artifactory Tomcat already started
2022-01-27T08:35:43.084Z [jfac] [WARN] [d84d2d549b318495] [o.j.c.ExecutionUtils:165] [pool-9-thread-2] - Retry 900 Elapsed 7.56 minutes failed: Registration with router on URL http://localhost:8046 failed with error: UNAVAILABLE: io exception. Trying again
That shows that the server is not running properly, but doesn't give a clear idea of what to try next. Any suggestions?
2 things to check,
How is the artifactory.service file in the systemd directory
Whenever the OS is rebooted, what is the error seen in the logs, check all the logs.
Hint: From the warning shared, it seems that Router service is not able to start when OS is rebooted, so whenever OS is rebooted and issue comes up check the router-service.log for any errors/warnings.
I am trying to deploy shiny server pro on a ubuntu 19.04 machine. I opted for the 45 days evaluation period where in Rstudio provides unrestricted access to shiny server pro features for the said period. But after setting up the server, I found out in the logs that my evaluation period had expired just after one day of use.
For setting up the server I followed the following steps:
Entered my details in the evaluation period form in this link https://rstudio.com/products/shiny-server-pro/evaluation/
I received a link in my mail which took me to the page which contains the commands to set up the R shiny pro server in ubuntu. This can be found here https://rstudio.com/products/shiny/download-commercial/ubuntu/
After following the steps,and changing the run_as parameter to my username in shiny-server.conf file I was able to get the server running. But found this in the logs:
[2019-10-15T14:05:28.424] [INFO] shiny-server - Shiny Server Pro v1.5.12.1023 (Node.js v10.15.3)
[2019-10-15T14:05:28.426] [INFO] shiny-server - Using config file "/etc/shiny-server/shiny-server.conf"
[2019-10-15T14:05:28.427] [INFO] shiny-server - Using non-persistent random cookie secret
[2019-10-15T14:05:28.467] [INFO] shiny-server - No authentication system configured.
[2019-10-15T14:05:28.469] [INFO] shiny-server - Starting listener on http://[::]:3838
[2019-10-15T14:05:28.478] [INFO] shiny-server - License type: traditional
[2019-10-15T14:05:28.539] [INFO] shiny-server - Licensing check succeeded.
[2019-10-15T14:05:28.541] [ERROR] shiny-server - Your evaluation has ended. Please activate!
I tried the same steps on an EC2 instance, but ran into the same problem.
for anyone facing a similar issue kindly note that I was able to resolve the above error by raising a ticket to Rstudio who acknowledged the same and were kind enough to provide me with a new trial period key
I'm getting error like this:
2018-01-16 09:56:17,354 [http-nio-8081-exec-8] [ERROR] (o.a.r.RemoteRepoBase:772) - IO error while trying to download resource 'pp-libs:ru/programpark/vector/10/vector-10.zip': org.apache.http.conn.ConnectTimeoutException: Connect to 192.168.3.20:8111 [/192.168.3.20] failed: connect timed out
in Artifactory log.
The file is half-gigabyte long and the channel to remote repo is not very wide.
Remote repo is an artifactory itself.
I'm not sure who closes the connection.
You need to increase the Socket Timeout in the Network Settings. See https://www.jfrog.com/confluence/display/RTF/Advanced+Settings