On Centos, I ran into the following error:
sudo snmptrap -v 2c -c read localhost '' UPS-MIB::upsTraps
MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs
Cannot find module (UPS-MIB): At line 0 in (none)
UPS-MIB::upsTraps: Unknown Object Identifier
The above error happened after
Copied UPS-MIB.txt to /usr/share/snmp/mibs
I started snmptrapd:
snmptrapd -f -Lo -Dread-config -m ALL
The version of the Net-SNMP is 5.2.x.
The same procedures work fine with Ubuntu 18.04/Net-SNMP 5.3.7.
I wonder how to debug and fix the problem?
Besides the Net-SNMP version difference, on Ubuntu, I found an instruction to install mib-download-tool, and execute it after the installation of Net-SNMP, and comment out the lines beginning with min: in snmp.conf in order to fix the error of missing MIB's.
However, for the Centos, I had no need and found no such instruction, thus I have not done it yet, as there is no error message of missing MIB's.
The MIB file is downloaded from https://tools.ietf.org/rfc/rfc1628.txt
renamed to UPS-MIB.txt (It seems to me that the name of the MIB file does not matter, as long as it's unique? I tried to use a different names, upsMIB.txt, rfc1628.txt, but it does not help to improve.)
I solved the problem as follows:
manually copied /usr/share/snmp/mibs/ietf/UPS-MIB on an Ubuntu with Net-SNMP 5.7.3 installed to the Centos /usr/share/snmp/mibs/UPS-MIB
then restart the snmpd
by the command:
service snmpd restart
then the OID of UPS-MIB becomes visible and accessible.
Maybe, the version that I downloaded from https://tools.ietf.org/rfc/rfc1628.txt is not suitable??
Related
I am getting issues when trying to install Perl modules on Ubuntu running on Windows 10.
I am not sure the best way to post the output, I am guessing maybe as "code"
$ cpan HTTP::Tiny
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/home/user/.cpan/Metadata'
Database was generated on Sun, 06 Nov 2022 23:29:01 GMT
Running install for module 'HTTP::Tiny'
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/CHECKSUMS
Checksum for /home/user/.cpan/sources/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz ok
sh: 1: /usr/bin/gzip: Exec format error
/usr/bin/tar: This does not look like a tar archive
/usr/bin/tar: Exiting with failure status due to previous errors
Uncompressed /home/user/.cpan/sources/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz successfully
Using Tar:/usr/bin/tar xf "HTTP-Tiny-0.082.tar":
Untarred HTTP-Tiny-0.082.tar successfully
'YAML' not installed, will not store persistent state
Package contains both files[HTTP-Tiny-0.082.tar] and directories[HTTP-Tiny-0.082]; not recognized as a perl package, giving up
Configuring D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz with Makefile.PL
Running make for D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz
make: *** No targets specified and no makefile found. Stop.
DAGOLDEN/HTTP-Tiny-0.082.tar.gz
/usr/bin/make -- NOT OK
I am really suck on how to fix this, I have been scratching my head for a few days now and any assistance would be really appreciated.
Based on the log it seems to be an issue specifically with Ubuntu 22.04 on WSL1:
sh: 1: gzip: Exec format error
see: gzip from Ubuntu Jammy doesn't execute #8219
You could install an earlier version of gzip via. apt that works well – however the best route would be to update to WSL 2, as it has many benefits and it won't have this issue.
See the comparison page including some rare cases where you might want to stay on WSL 1.
I am having an issue with a lab server I am running using CentOS 9, when I'm trying to install Grafana, the GPG check fails. This is the output I get:
Importing GPG key 0x24098CB6:
Userid : "Grafana <info#grafana.com>"
Fingerprint: 4E40 DDF6 D76E 284A 4A67 80E4 8C8C 34C5 2409 8CB6
From : https://packages.grafana.com/gpg.key
Is this ok [y/N]: y
Key import failed (code 2). Failing package is: grafana-8.5.5-1.x86_64
GPG Keys are configured as: https://packages.grafana.com/gpg.key
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
When I try the same on my local Fedora 35 machine, I get this:
Importing GPG key 0x24098CB6:
Userid : "Grafana <info#grafana.com>"
Fingerprint: 4E40 DDF6 D76E 284A 4A67 80E4 8C8C 34C5 2409 8CB6
From : https://packages.grafana.com/gpg.key
Is this ok [y/N]: y
Key imported successfully
Running transaction check
The packages being downloaded are the same grafana-8.5.5-1.x86_64.rpm, I am using dnf for both installations, and the grafana.repo files are both the same:
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
I know I could just turn off the gpg checking, but I am not comfortable with a solution like that.
Any help resolving this would be greatly appreciated! Let me know if I should supply any more information.
I've quite recently swapped over to CentOS and Fedora, so I apologize if this has been resolved before, but I was unable to find it.
There has been some change with the default crypto policies in CentOS streams 9.
update-crypto-policies --set DEFAULT:SHA1
The packages need to be re-signed with a SHA256 or SHA521 key instead of SHA1.
Ref: https://access.redhat.com/articles/6846411
I'm running into a fatal error when I'm trying to import using Mongodb 3.3.9. My script has worked before, but when I upgraded my Mac os to Sierra, I'm running into what looks like a Go language problem.
Error received :
fatal error: MSpanList_Insert
runtime stack: runtime.MSpanList_Insert(0x491d30, 0x54daf0)
/usr/local/go/src/runtime/mheap.c:692 +0x8f
runtime.MHeap_Alloc(0x491cc0, 0x2, 0x10000000026, 0xdbc9)
/usr/local/go/src/runtime/mheap.c:240 +0x66
runtime.MCentral_CacheSpan(0x49b0b8, 0x34872)
/usr/local/go/src/runtime/mcentral.c:85 +0x167
runtime.MCache_Refill(0x527c20, 0xc200000026, 0x5550b8)
/usr/local/go/src/runtime/mcache.c:90 +0xa0
Others have noted a similar problem that was supposed to be resolved in an earlier version (mongorestore random crash (fatal error)), but my problem persists.
As the comments suggested, it's solved reinstalling mongo. If you install it using brew execute: brew uninstall mongo.
If you just followed the steps in their tutorial, just delete the executable. If you don't know how, follow this:
which mongo
#now you have a path
rm -rf yourMongoPath
sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist
worked for me
I am using neo4j enterprise 3.0.3 version for windows. Following the operations manual 3.0, I have installed the neo4j service with bin\neo4j install-service. But I can't start it with bin\neo4j start. It said
Invoke-Neo4j : Failed to start service 'Neo4j Graph Database - neo4j (neo4j)'.
And I can't start the neo4j service in windows serice either. Maybe anyone have encountered this case before?
I had the same problem: I am using neo4j community 3.1.2 for windows and installed the service with the neo4j.bat file without any problems.Then i wanted to start the service with neo4j.bat and got the same error as you
I found a solution that worked for me. My neo4j files were in a folder, where the path to the folder contained spaces (C:\Program Files\Neo4j) Then i moved the folder one level up (C:\Neo4j).
After that i could start the service without problems.
Maybe this solution helps.
I am running neo4j on windows and in my case the crux of the issue was that there was an incompatibility between the installed versions of Java (32-bit) v/s OS version. The biggest clue that led me to this is the following set of lines in neo4j-service.2018-08-03 log file
[2018-08-03 14:55:42] [info] [ 1432] Starting service...
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] Failed creating java C:\JavaNew\bin\server\jvm.dll
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] ServiceStart returned 1
There are a fair number of potential issues, and I have made an attempt to compile all the issues with this,
Windows services cannot deal with service names in folders that have spaces; especially if there is another folder with the same name as the one with spaces.
For example - C:\Program Files... will have issues if C:\Program\Something...
To work around this, I put Neo4j in root folder c:\Neo4j
Get-Java.ps1 (under ..\bin\Neo4j-Management folder)looks in the path variable for 'JAVA_HOME' (usually found in *nix environments). If it does not find it here, it keeps looking in registry, and finally throws up its hand!
To deal with this, I simply put in a path variable. For a good measure, I uninstalled Java and re-installed Java in the root folder under C:\JavaNew
In retrospect, this step is probably not on part of the problem, and hence can be ignored. But I am leaving it here for completeness sake.
Invoke-Neo4j.ps1 (also under ..\bin\Neo4j-Management folder) has code that determines if the OS is 32-bit (or 64-bit). Based on this it determines if it should run prunsrv-i386.exe (32-bit) or prunsrv-amd64.exe (64-bit).
This has to match the Java version installed.
Upon running java -XshowSettings:all, and inspecting the sun.arch.data.model value (32, in my case), I realized that my OS is 64 bit and the Java version is 32-bit.
To deal with this, I put in code (very klugey!). I am sure there are much better ways to get to the same outcome, but this is what I used.
switch ( (Get-WMIObject -Class Win32_Processor | Select-Object -First 1).Addresswidth ) {
32 { $PrunSrvName = 'prunsrv-i386.exe' } # 4 Bytes = 32bit
#64 { $PrunSrvName = 'prunsrv-amd64.exe' } # 8 Bytes = 64bit COMMENTED as a workaround!!!
64 { $PrunSrvName = 'prunsrv-i386.exe' } # 8 Bytes = 64bit
Now, uninstall the neo4j service, install it, and start the service.
Hope this works for you.
neo4j console
Posting for latest versions > 4.x
I had the same issue using neo4j start, Neo4j console is the right command I was looking for. It is a web-based graph that acts as an interactive tutorial.
i had the same problem , after the neo4j worked for few weeks it stoop working (without any change that i made)
i have set java_home uninstall and install and now it works
neo4j-enterprise-3.3.4
I was also having weired issue as there was no error but neo4J service did not start.
[xx#ss1 bin]$ ./neo4j console
[xx#ss1 bin]$ .
The problem was with the permission on Java directory and I tried
chmod -R 777 jdk_directory
and problem got solved.
#neo4j #neo4jnotstarting
After I build incubator-hawq on Centos7.1, I tried to init it. But the error below occurs:
20160516:18:10:43:002036 hawqinit.sh:host-172-16-0-105:hawqadmin-[INFO]:-Loading hawq_toolkit...
ALTER ROLE
20160516:18:10:44:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-20160516:18:10:43:002036 hawqinit.sh:host-172-16-0-105:hawqadmin-[INFO]:-Loading hawq_toolkit...
20160516:18:10:44:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-Master init successfully
20160516:18:10:44:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-Init segments in list: ['hawq-master']
20160516:18:10:44:001766 hawq_init:host-172-16-0-105:hawqadmin-[DEBUG]:-Start to init segment on node 'hawq-master'
20160516:18:10:44:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-Total segment number is: 1
fgets failure: Success
The program "postgres" is needed by initdb but was either not found in the same directory as "/usr/hawq/bin/initdb" or failed unexpectedly.
Check your installation; "postgres -V" may have more information.
20160516:18:10:45:002318 hawqinit.sh:host-172-16-0-105:hawqadmin-[ERROR]:-Postgres initdb failed
20160516:18:10:45:002318 hawqinit.sh:host-172-16-0-105:hawqadmin-[ERROR]:-Segment init failed on host-172-16-0-105
20160516:18:10:45:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-20160516:18:10:45:002318 hawqinit.sh:host-172-16-0-105:hawqadmin-[ERROR]:-Postgres initdb failed
20160516:18:10:45:002318 hawqinit.sh:host-172-16-0-105:hawqadmin-[ERROR]:-Segment init failed on host-172-16-0-105
20160516:18:10:45:001766 hawq_init:host-172-16-0-105:hawqadmin-[ERROR]:-HAWQ init failed on hawq-master
20160516:18:10:46:001766 hawq_init:host-172-16-0-105:hawqadmin-[INFO]:-0 of 1 segments init successfully
20160516:18:10:46:001766 hawq_init:host-172-16-0-105:hawqadmin-[ERROR]:-Segments init failed, exit
When I type the command, the below shows:
[hawqadmin#host-172-16-0-105 hawqAdminLogs]$ postgres -V
postgres (HAWQ) 8.2.15
Any advice? Thanks!
If "postgres -V" works, that means the postgres binary is good.
Before you do "hawq init cluster", please make sure:
1) $GPHOME in greenplum_path.sh is correctly set to the directory of hawq binary, i.e, /usr/hawq in your case
2) source $GPHOME/greenplum_path.sh
3) check if initdb and postgres binary is in $GPHOME/bin
From the error you pasted above, 2 possible causes:
(1) The binary postgres called is not /usr/hawq/bin/postgres, You can use which postgres to check the path.
(2) The dependent lib for postgres may be wrong. You can use ldd for linux or otool for mac to print all dependent lib paths, and check them.
Moreover, if any error when init hawq, please check log in ~/hawqAdminLogs/, you may find out the specific error message.
Hope it will help you to find out the root cause.
Recently I faced same error while initializing cluster.
Postgres -V showed correct version, which postgres showed /usr/local/hawq/bin/postgres, also the path was already set, still faced above error.
Finally resolved by setting LD_LIBRARY_PATH to /usr/local/hawq/lib/ and sourced it via .bashrc file.
Looks like you might have installed hawq binaries in different directory . Please check the following
1.Make sure you have all the right PATH set
Check hawq initdb binaries are there in /usr/hawq/bin/ directory
make sure you have successed compile hawq and install them
check postgres is in the same dir with initdb
if there are more than 1 postgres in your pc, make sure the path of postgres(the same dir with initdb) is in your PATH.