I use avahi v0.7 compiled with buildroot 2019.02 to armv7 target.
The compilation works fine.
After service start or system start, I can ping (from other computer) my device with ping wpb-the.local. But after few minutes 1 or 2 (on the same computer) I got ping: wpb-the.local: Name or service not known from Ubuntu or Ping request could not find host wpb-the.local. Please check the name and try again. from windows.
On device side the daemon still running and there is no error in messages.
And if I stop the service and restart it, then it's working during few minutes again.
I don't understand why. Do you have any hint ?
Best regards
JM
Related
I am installing openstack on a new server using devstack. I am having this error no matter the type of installation i do. I am installing on the host computer. I tried the exact same installation on another computer and it's fine and the openstack is working, however i kept on having this error on this cpu. I even formatted the computer and reinstalled the ubuntu 16 and 18 and, but whenever i tried to install openstack i kept on having this error. I haven't seen this type of error before and I don't know why the error is there, is it from the OS, the CPU or openstack. I tried different branches, rocky, stein, train or queens. its always the same. I tried this installation on another computer and it worked fine
The world dump file can be found here enter link description here
It's pretty tricky, I guess i used the same wifi adapter with my previous openstack cpu, so the ip address are the same. However i changed the password, so, openstack feels like the account for the ip address exist but the password is different. so it couldn't authenticate some keystone commands and it's failing.
So here is how is discovered the problem, i tested the installation with a static ip, via an ethernet cable, and i discovered the error wasn't there. Then i realized that the host IP address that is used in this server is the same as the previous server. Interesting, So I connected back to the wifi adapter, the same IP address, and i used the same password as the previous cpu. and it worked fine, Installation went through ... Lol, i battled this for more than 3 days, very tricky.
I have a Windows Server 2016 that used to run Tableau Server v2018.1 (and a few versions before that); during this last update, I performed a backup and continued to wipe Tableau off the server (used the tableau-obliterate script which removed all things Tableau).
I then proceeded to install Tableau v2018.2 as a clean install, set up the configuration to use port 80 and started the server successfully.
However, I quickly discovered that Tableau moved the gateway to port 8000; I proceeded to review the ports to ensure nothing else is using this (this VM has nothing other than Tableau installed on it); I used TCPView and monitored the ports while the Tableau Server was running and Stopping/Starting; the only hint I found of something touching port 80 was the output of netstat, which showed an entry of TCP vizqlserver.exe with the state of CLOSE_WAIT.
I have tried manually setting the port through TSM configuration (run set, confirm with get, restart), TSM Settings import, and manually adjusting the configuration file for gateway, but Tableau just reverts back to port 8000.
I am at a loss as to why this is happening as again, nothing else has ever been on this server and nothing has changed since removing v2018.1 (which was running on port 80).
I tried to post this on the Tableau community forum, but 20 hrs later, it is still pending moderator approval :(
Would appreciate any help!
A recent Windows update has been causing some port conflicts try this:
https://kb.tableau.com/articles/Issue/kb4338818-windows-update-causing-tableau-server-to-become-unstable
My jbossews cartridge is suddenly no more available through the webbrowser but when logged in via SSH it seems to be reachable:
What I've done so far:
When I gear restart my cartrdige, I get Found 127.3.72.129:8080 listening port.
wget 127.3.72.129:8080 actually downloads the valid index.html
With a wget on the external domain wget test-locked.rhcloud.com (also with ":8080") I just get Connection refused
Catalina log also gives no hint about any problems. It reports the server to be started up successfully without any warnings.
access log also shows no request at all coming in.
disk quota is available, too
I'm running out of ideas what I could check next or get the gear up and running again. Any help would be appreciated.
After Openshift having recovered like magically, the answer to such an issue seems to be: "relax, wait and see".
i have a strange Problem with Nagios. After restart everything runs perfectly fine.
Then some hours later, Hosts are shown down and a minute later up again(see History log below). After that all Services fail with a timeout.
This doesn´t happen with all Servers at the same time. It seems rather randomly which Server fails.
History log:
[2013-06-26 19:19:07] SERVICE ALERT: HyperV 1;Check CPU HyperV 1;CRITICAL;SOFT;1;CHECK_NRPE: Socket timeout after 120 seconds.
[2013-06-26 19:17:27] HOST ALERT: HyperV 1;UP;SOFT;2;PING OK - Packet loss = 0%, RTA = 3.01 ms
[2013-06-26 19:16:17] HOST ALERT: HyperV 1;DOWN;SOFT;1;PING CRITICAL - Packet loss = 100%
What i have tried so far.
-Increased the timeouts
-Changed the Host check, so that it get checked more often before fail (5 times instead of 1)
-Executed the scripts from command line -> Also fail (maybe Ubuntu problem?)
-Checked Logs on both sides for errors (nothing found)
After a restart everything is fine again.
System Infos:
-Nagios is running on an Ubuntu 13.04
-Some clients are running different Windows with NSClient++
-ESX with Versions from 4.0 to 5.1
Plugins:
-check_nrpe
-check_vmfs from Nagios Exchange
I sth. is unclear don´t hesitate to ask.
Thx & Best,
Pille
You seem to have a networking issue, not a Nagios issue. Possibly a bad cable, failing NIC, routing problem, switch flapping, arp table overflow, could be any number of things.
Since this affects all hosts/services, and intermittently, and clears itself up, I would suggest you start looking for a problem on your local connections first. If it only affects some items and not others, then find which hosts have common network components and check there.
I am writing a script that powers on a system via network. And then i need to run a few commands on the other host. How do I know whether the system has powered on?
My programming language is Perl and the target host is RHEL5.
Is there any kernel interrupt or network boot information that indicates the system has powered on and the os has loaded?
[In a different scenario] I was also wondering just in case if i just switch on my Machine manually. when is it exactly said to have powered on. and when is the OS is supposed to have booted completely for a network related operation such as executing a network command there. What if the system is on DHCP how would a remote system then search for this machine [i guess it is possible via mac address. but if i am wrong ].
If I have missed out any info please feel free to ask me. If you have any suggestions to make the task easier please surface them :)
thanx
imkin
Well, I'd say the system is booted when it can perform the request you've made of it. That is, the sshd daemon is running. That's booted sufficiently for your purposes (I assume - substitute for whatever daemon you really need).
So, I'd send the power-on signal, and check back every 15-30 seconds to see if I could connect. If I've failed to connect within whatever is a reasonable time for that machine (2 minutes or 5 minutes or whatever), then I'd send an alert to the IT support team. Well, I'd send it to myself first, and only once I've investigated a few failures or so and found them to all be legitimate would I start sending it directly to IT.
DHCP is kind of a different question. You'd have to start learning about broadcasting, or having a daemon on that machine "call home" during boot to register its current IP address. And it would have to "call home" every time a DHCP renewal changed its IP address. This is decidedly more convoluted. Try to avoid DHCP on such server machines if at all possible.
On the rebooting machine you can install a script in your crontab with the special #reboot assertion (see man 5 crontab). That script could send a notification of some kind to the other machine, notifying it that it's up now.
I think checking for sshd sounds like a good approach.
As for the DHCP problem: if the other computer is on the same subnet you can look it up by MAC address using Net::ARP.
How about adding a script to the remote machine which gets run on startup to have it tell you when it is ready.