Ran into this JVM error after running an process for an extended period of time that reads records from a csv file, validates the data, and stores in in a database. Using Hibernate and PostgreSQL. The JVM dump mentions some psql classes. Can anyone help with this?
Additional noteworthy infomation:
The process slows down over time but keeps a consistent CPU and memorry usage (about 150% CPU and 11.5% memory)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000073f4027bb, pid=977, tid=1111066944
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C 0x000000073f4027bb
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00000000537bd000): GCTaskThread [stack: 0x0000000042298000,0x0000000042399000] [id=985]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x0000000000000003, RDX=0x0000000740c37298
RSP=0x0000000042397b38, RBP=0x0000000042397bb0, RSI=0x00000007f65092b8, RDI=0x0000000740c372a8
R8 =0x0000000000000012, R9 =0x0000000000000012, R10=0x00000007f6fdafb9, R11=0x00002aaaaf38bf10
R12=0x00000007f65092b8, R13=0x0000000000000005, R14=0x0000000000000000, R15=0x0000000740c30ac0
RIP=0x000000073f4027bb, EFLAGS=0x0000000000010286, CSGSFS=0x0000000000000033, ERR=0x0000000000000006
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x0000000042397b38)
0x0000000042397b38: 00002b776b7c8dea 168cf3000000aacb
0x0000000042397b48: 00002b776baf73d0 168cf3000000aacc
0x0000000042397b58: 0000000053802720 0000000053802720
0x0000000042397b68: 0000000000000009 168cf3000000aacc
0x0000000042397b78: 00000007f6fdb02d 0000000042397ba0
0x0000000042397b88: 00000007f6fdafb8 00002b776bb09ee0
0x0000000042397b98: 00000000538027a0 0000000000000000
0x0000000042397ba8: 0000000000000001 0000000042397bd0
0x0000000042397bb8: 00002b776b7c914d 0000000053802720
0x0000000042397bc8: 0000000053802788 0000000042397c10
0x0000000042397bd8: 00002b776b7c85bf 00000007f6fdafb9
0x0000000042397be8: 0000000053802720 0000000000000006
0x0000000042397bf8: 00002aaab4cfe410 00002b776bb04f20
0x0000000042397c08: 0000000042397c2c 0000000042397c60
0x0000000042397c18: 00002b776b7cb948 0000000042397c30
0x0000000042397c28: 2ec7c4dd6b4cdc27 00000007f60b61ba
0x0000000042397c38: 00002b776baedc24 00002aaab4cfe410
0x0000000042397c48: 00000000537bd000 00002b776b937aa6
0x0000000042397c58: 0000000000000000 0000000042397d60
0x0000000042397c68: 00002b776b4ceefa 0000000042397cb0
0x0000000042397c78: 0000000042397c88 00002b776bb08ac0
0x0000000042397c88: 0000000000000000 00000000537bd4d0
0x0000000042397c98: 00000000537bd500 00000000537bd510
0x0000000042397ca8: 00000000537bd8e8 00000000537bd000
0x0000000042397cb8: 00000000537bd8f0 00000000537bd920
0x0000000042397cc8: 00000000537bd930 00000000537bdd08
0x0000000042397cd8: 0000000042397d00 00000000537bd4d0
0x0000000042397ce8: 00000000537bd500 00000000537bd510
0x0000000042397cf8: 00000000537bd8e8 00000000537bd000
0x0000000042397d08: 00000000537bd8f0 00000000537bd920
0x0000000042397d18: 00000000537bd930 00000000537bdd08
0x0000000042397d28: 00000000537bdd10 00000000537be630
Instructions: (pc=0x000000073f4027bb)
0x000000073f40279b: e7 00 00 00 00 14 00 6a 61 76 61 2f 75 74 69 6c
0x000000073f4027ab: 2f 50 72 6f 70 65 72 74 69 65 73 00 00 01 72 99
0x000000073f4027bb: 4a 0f 00 00 00 78 00 e8 e7 00 00 00 00 10 00 6a
0x000000073f4027cb: 61 76 61 2f 75 74 69 6c 2f 56 65 63 74 6f 72 00
Register to memory mapping:
RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x0000000000000003 is an unknown value
RDX=0x0000000740c37298 is an oop
{method}
- klass: {other class}
RSP=0x0000000042397b38 is an unknown value
RBP=0x0000000042397bb0 is an unknown value
RSI=0x00000007f65092b8 is an unknown value
RDI=0x0000000740c372a8 is an oop
{method}
- klass: {other class}
R8 =0x0000000000000012 is an unknown value
R9 =0x0000000000000012 is an unknown value
R10=0x00000007f6fdafb9 is an unknown value
R11=0x00002aaaaf38bf10 is an unknown value
R12=0x00000007f65092b8 is an unknown value
R13=0x0000000000000005 is an unknown value
R14=0x0000000000000000 is an unknown value
R15=0x0000000740c30ac0 is an oop
{constant pool}
- klass: {other class}
- cache: 0x0000000740c4f550
- 1 : : klass_index=110 name_and_type_index=300
- 2 : : klass_index=109 name_and_type_index=301
- 3 : : klass_index=110 name_and_type_index=302
- 4 : : klass_index=109 name_and_type_index=303
- 5 : : klass_index=304 name_and_type_index=305
- 6 : : klass_index=306 name_and_type_index=307
- 7 : : klass_index=304 name_and_type_index=308
- 8 : : klass_index=109 name_and_type_index=309
- 9 : : klass_index=109 name_and_type_index=310
- 10 : : klass_index=109 name_and_type_index=311
- 11 : : 'org/postgresql/core/Field'
- 12 : : 'java/util/Vector'
- 13 : : klass_index=12 name_and_type_index=314
- 14 : : klass_index=109 name_and_type_index=315
- 15 : : klass_index=109 name_and_type_index=316
- 16 : : klass_index=109 name_and_type_index=317
- 17 : : 'java/lang/String'
- 18 : : "*" {0x73f6b2b18}
- 19 : : klass_index=109 name_and_type_index=320
- 20 : : klass_index=109 name_and_type_index=321
- 21 : : "8.2" {0x740a78928}
- 22 : : klass_index=323 name_and_type_index=324
- 23 : : 'org/postgresql/util/PSQLException'
- 24 : :
The last time something like that happened to me, I found that the main memory on my computer was damaged, I know, I know, most likely everything's ok, but if I were you, i will check it out with memtest86+
Related
I am trying to secure the Akka Management port of a Scala microservice with TLS by starting Akka Management programatically on port 8558 via AkkaManagement:withHttpsConnectionContext().
When the Scala service is run, it reads from the configuration and starts Akka Management fine, but does not appear to be operating with TLS encryption enabled.
~$ telnet localhost 8558
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /cluster/members HTTP/1.0
Host: 127.0.0.1
HTTP/1.1 200 OK
Server: akka-http/10.4.0
Date: Fri, 27 Jan 2023 20:26:00 GMT
Connection: close
Content-Type: application/json
Content-Length: 439
From what I can tell, Akka Management is serving HTTP from what should be the HTTPS port, and not encrypting the response.
:~$ openssl s_client -connect localhost:8558 -state -debug
CONNECTED(00000003)
SSL_connect:before SSL initialization
write to 0x56097b12c740 [0x56097b13ee80] (283 bytes => 283 (0x11B))
0000 - 16 03 01 01 16 01 00 01-12 03 03 05 27 1c 50 1b ............'.P.
0010 - e6 b6 23 5a e5 da d5 48-29 33 51 08 13 fb b6 aa ..#Z...H)3Q.....
0020 - 23 f4 2e 44 93 75 95 97-59 9a 1c 20 99 b0 36 06 #..D.u..Y.. ..6.
0030 - 1f 3d 79 d0 d8 e8 36 7e-41 5e 2e ff 70 f7 ce a5 .=y...6~A^..p...
0040 - 0a 5a 56 e4 a9 fc 15 09-d0 3c a7 9b 00 3e 13 02 .ZV......<...>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 8b ...=.<.5./......
0090 - 00 0b 00 04 03 00 01 02-00 0a 00 0c 00 0a 00 1d ................
00a0 - 00 17 00 1e 00 19 00 18-00 23 00 00 00 16 00 00 .........#......
00b0 - 00 17 00 00 00 0d 00 2a-00 28 04 03 05 03 06 03 .......*.(......
00c0 - 08 07 08 08 08 09 08 0a-08 0b 08 04 08 05 08 06 ................
00d0 - 04 01 05 01 06 01 03 03-03 01 03 02 04 02 05 02 ................
00e0 - 06 02 00 2b 00 05 04 03-04 03 03 00 2d 00 02 01 ...+........-...
00f0 - 01 00 33 00 26 00 24 00-1d 00 20 4e 63 c8 62 95 ..3.&.$... Nc.b.
0100 - f3 8e a4 b2 04 44 1a 83-6e 53 99 4b ef d0 f7 51 .....D..nS.K...Q
0110 - eb 95 b5 8c 1d 3c f7 f7-fa c1 1b .....<.....
SSL_connect:SSLv3/TLS write client hello
read from 0x56097b12c740 [0x56097b135c63] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
SSL_connect:error in error
139911147234624:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 189 (0xBD))
0000 - 31 2e 31 20 34 30 30 20-42 61 64 20 52 65 71 75 1.1 400 Bad Requ
0010 - 65 73 74 0d 0a 53 65 72-76 65 72 3a 20 61 6b 6b est..Server: akk
0020 - 61 2d 68 74 74 70 2f 31-30 2e 34 2e 30 0d 0a 44 a-http/10.4.0..D
0030 - 61 74 65 3a 20 46 72 69-2c 20 32 37 20 4a 61 6e ate: Fri, 27 Jan
0040 - 20 32 30 32 33 20 32 30-3a 33 36 3a 30 32 20 47 2023 20:36:02 G
0050 - 4d 54 0d 0a 43 6f 6e 6e-65 63 74 69 6f 6e 3a 20 MT..Connection:
0060 - 63 6c 6f 73 65 0d 0a 43-6f 6e 74 65 6e 74 2d 54 close..Content-T
0070 - 79 70 65 3a 20 74 65 78-74 2f 70 6c 61 69 6e 3b ype: text/plain;
0080 - 20 63 68 61 72 73 65 74-3d 55 54 46 2d 38 0d 0a charset=UTF-8..
0090 - 43 6f 6e 74 65 6e 74 2d-4c 65 6e 67 74 68 3a 20 Content-Length:
00a0 - 32 33 0d 0a 0d 0a 55 6e-73 75 70 70 6f 72 74 65 23....Unsupporte
00b0 - 64 20 48 54 54 50 20 6d-65 74 68 6f 64 d HTTP method
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 0 (0x0))
It also looks like attempting to access Akka Management with TLS is also failing completely.
I'm seeing the following log message on the microservice when using the openssl command:
[WARN] [akka.actor.ActorSystemImpl] [] [inbound-transaction-akka.actor.default-dispatcher-65] [] [] [] [] - Illegal request, responding with status '400 Bad Request': Unsupported HTTP method: The HTTP method started with 0x16 rather than any known HTTP method from 192.168.96.1:39184. Perhaps this was an HTTPS request sent to an HTTP endpoint?
I tried starting Akka Management programatically with TLS encryption, and got unencrypted HTTP instead.
Here is the code used to setup HTTPS and start Akka Management:
def getHttpsConnectionContext(config: HttpsConfig): SSLContext = {
val keystore: KeyStore = KeyStore.getInstance("PKCS12")
val keystoreFile: InputStream =
getClass.getClassLoader.getResourceAsStream(config.keystoreFile)
val keystorePassword = config.keystorePassword.toCharArray
keystore.load(keystoreFile, keystorePassword)
val keyManagerFactory: KeyManagerFactory =
KeyManagerFactory.getInstance("SunX509")
keyManagerFactory.init(keystore, keystorePassword)
val trustManagerFactory: TrustManagerFactory =
TrustManagerFactory.getInstance("SunX509")
trustManagerFactory.init(keystore)
val sslContext: SSLContext = SSLContext.getInstance("TLS")
sslContext.init(
keyManagerFactory.getKeyManagers,
trustManagerFactory.getTrustManagers,
new SecureRandom
)
sslContext
}
val httpsConfig: HttpsConfig =
HttpsConfig(
actorSystem.settings.config,
"akka.moo.https"
) match {
case Some(value) => value
case None => throw new ConfigurationException("Bad HTTPS config")
}
val sslContext: SSLContext =
HttpsContext.getHttpsConnectionContext(httpsConfig)
val httpsServer: HttpsConnectionContext =
ConnectionContext.httpsServer(sslContext)
val management = AkkaManagement(actorSystem)
management.start(_.withHttpsConnectionContext(httpsServer))
I'm not sure what the problem here is.
Thank you ahead of time for your help.
I want to dump (and later work with) the paths of the locally changed files in my SVN repository. Problem is, there are umlauts in some filenames (like ä, ö, ü).
When I open a powershell window in my lokal trunk folder, I can do svn status and get the result with correct umlauts ("ü" in this case):
PS C:\trunk> svn status -q
M Std\ClientComponents\Prüfung.xaml
M Std\ClientComponents\Prüfung.xaml.cs
M Std\ClientComponents\PrüfungViewModel.cs
When I do the same in my powershell script, the results are different.
Script "DumpChangedFiles.ps1":
foreach ( $filename in svn status -q )
{
Write-Host $filename
}
Results:
PS C:\trunk> .\DumpChangedFiles.ps1
M Std\ClientComponents\Pr³fung.xaml
M Std\ClientComponents\Pr³fung.xaml.cs
M Std\ClientComponents\Pr³fungViewModel.cs
Question: Why are the umlauts wrong? How do I get to the correct results?
Hex-Dump:
ef bb bf 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 2e 78 61 6d 6c 0d 0a 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 2e 78 61 6d 6c 2e 63 73 0d 0a 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 56 69 65 77 4d 6f 64 65 6c 2e 63 73
Here's the output of the script DumpChangedFiles.ps1 compared to the output of your desired command:
PS C:\trunk> .\DumpChangedFiles.ps1
M Std\ClientComponents\Pr³fung.xaml
M Std\ClientComponents\Pr³fung.xaml.cs
M Std\ClientComponents\Pr³fungViewModel.cs
PS C:\trunk> $PSDefaultParameterValues['*:Encoding'] = 'utf8'; svn status -q
M Std\ClientComponents\Prüfung.xaml
M Std\ClientComponents\Prüfung.xaml.cs
M Std\ClientComponents\PrüfungViewModel.cs
Output of SVN--version is:
PS C:\trunk> svn --version
svn, version 1.14.0 (r1876290)
compiled May 24 2020, 17:07:49 on x86-microsoft-windows
Copyright (C) 2020 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme
The following authentication credential caches are available:
* Wincrypt cache in C:\Users\reichert\AppData\Roaming\Subversion
The problem comes from PowerShell ISE, the svn command in your script is executed through PowerShell ISE which encode its output with Windows-1252 (or your default windows locales).
You can go with the following to get a correct output (check your Windows locales) :
[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(1252)
foreach ( $filename in svn status -q )
{
Write-Host $filename
}
It seems a previous unanswered question relates to the same problem with ISE :
Powershell ISE has different codepage from Powershell and I can not change it
I need some help to understand the avcC atom structure of a particular mp4 sample I am trying to analyze.
Hex dump:
00 00 00 38 61 76 63 43 01 64 00 1F FF E1 00 1C 67 64 00 1F AC D9 80
50 05 BB 01 6A 02 02 02 80 00 00 03 00 80 00 00 1E 07 8C 18 CD 01 00
05 68 E9 7B 2C 8B FD F8 F8 00 00 00 00 13 63 6F 6C 72
This is what I understand from the above:
00 00 00 38 Size of avcC atom
61 76 63 43 avcC signature
01 configurationVersion
64 AVCProfileIndication
00 profile_compatibility
1F AVCLevelIndication
FF 111111b + lengthSizeMinusOne
E1 111b + numOfSequenceParameterSets (in this case, 1 SPS)
00 1C SPS length (in this case, 28 bytes)
67 64 00 1F AC D9 80 50 05 BB 01 6A 02 02 02 80 00 00 03 00 80 00 00 1E 07 8C 18 CD SPS data (28 bytes as per above)
01 numOfPictureParameterSets (in this case, 1 PPS)
00 05 PPS length
This is where the problem begins. Based on the PPS length given by the previous bytes, the next 5 bytes should be the PPS data: 68 E9 7B 2C 8B
However according to the avcC header, the total length of the atom is 56 bytes (0x38), which means that the following 4 bytes should be included: FD F8 F8 00
But the problem is that the PPS length is given as 5 bytes (0x05). So what exactly are these final 4 bytes?
Then follows the header of the colr atom:
00 00 00 13 size of colr atom
63 6F 6C 72 colr signature
Which I have checked and is indeed 19 bytes in length (0x13).
The problem is with the avcC atom and with that particular mp4 sample I am analyzing (I've checked other samples too and they didn't have this peculiarity).
You can find the sample here.
EDIT
mp4info tool from the bento4 suite reports the following as the avcC atom's size: 8+48
And mp4dump reports:
AVC SPS: [6764001facd9805005bb016a02020280000003008000001e078c18cd]
AVC PPS: [68e97b2c8b]
So it correctly reports the total size of the atom as 56 bytes (0x38) based on what is found in the avcC header, but the SPS/PPS data are analyzed the same way as above. I still don't understand what the final 4 bytes are or where do they belong.
I dind't get any answer but fortunately a bit more careful reading of ISO 14496-15 solved this issue:
if( profile_idc == 100 || profile_idc == 110 ||
profile_idc == 122 || profile_idc == 144 )
{
bit(6) reserved = ‘111111’b;
unsigned int(2) chroma_format;
bit(5) reserved = ‘11111’b;
unsigned int(3) bit_depth_luma_minus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bit_depth_chroma_minus8;
unsigned int(8) numOfSequenceParameterSetExt;
for (i=0; i< numOfSequenceParameterSetExt; i++) {
unsigned int(16) sequenceParameterSetExtLength;
bit(8*sequenceParameterSetExtLength) sequenceParameterSetExtNALUnit;
}
}
Apparently a sequence of 4+ bytes may exist at the end of an avcC atom depending on the profile used. In my sample above the profile is 100 (0x64), hence it meets the criteria. So the last 4 bytes are:
FD = bits 111111 are reserved, remaining 01 means chroma subsampling 4:2:0
F8 = bits 11111 are reserved, remaining 000 means luma bit depth is 8
F8 = bits 11111 are reserved, remaining 000 means chroma bit depth is 8
00 = zero SPS extensions
I am using a REINER SCT cyberJack RFID standard card reader and an estonian ID card.
pcsc_scan correctly identifies the card:
$ pcsc_scan
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau#free.fr>
Using reader plug'n play mechanism
Scanning present readers...
0: REINER SCT cyberJack RFID standard (9084002233) 00 00
Wed Mar 13 14:02:39 2019
Reader 0: REINER SCT cyberJack RFID standard (9084002233) 00 00
Card state: Card inserted,
ATR: 3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
ATR: 3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
+ TS = 3B --> Direct Convention
+ T0 = DB, Y(1): 1101, K: 11 (historical bytes)
TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
TC(1) = 00 --> Extra guard time: 0
TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0
-----
TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1
-----
TA(3) = FE --> IFSC: 254
TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following
-----
TA(4) = 83 --> Clock stop: state H - Class accepted by the card: (3G) A 5V B 3V
+ Historical bytes: 00 12 23 3F 53 65 49 44 0F 90 00
Category indicator byte: 00 (compact TLV data object)
Tag: 1, len: 2 (country code, ISO 3166-1)
Country code: 23 3F
Tag: 5, len: 3 (card issuer's data)
Card issuer data: 65 49 44
Mandatory status indicator (3 last bytes)
LCS (life card cycle): 0F (unknown)
SW: 9000 (Normal processing.)
+ TCK = F1 (correct checksum)
Possibly identified card (using /home/mag/.cache/smartcard_list.txt):
3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
Estonia ID-card (eID)
https://id.ee
however pkcs11-tool does not see the card:
$ pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -L
Available slots:
Slot 0 (0x0): REINER SCT cyberJack RFID standard (9084002233) 00 00
(empty)
What can be the cause of the problem? What do I miss?
Apparently the toolchain of the estonian card is not compatible with pkcs-11. However the chrome-token-signing package contains the needed code at least for authentication to their service both for chromium and firefox, and the qdigidoc4 package contains a tool to create and check signed/encrypted documents.
Their repo is here:
deb https://installer.id.ee/media/ubuntu/ bionic main
Another issue I have encountered that my cert is said to be invalid. That was because the certificate won't get enabled right away when you receive your ID.
Here is a part of the snmptt log file :
Tue May 17 22:20:47 2016 .1.3.6.1.4.1.31023.1.1.1.0.1 Normal "Status Events" ssav02 - ef47e072-c8e1-46ef-8c70-645a69bdd489 Backup Job 1 Success
Tue May 17 23:00:03 2016 .1.3.6.1.4.1.1302.3.1.2.8.0.5 INFORMATIONAL "Status Events" ssav02 - User advised of event: 42 61 63 6B 75 70 20 45 78 65 63 3A 20 44 E9 62 75 74 20 64 75 20 74 72 61 76 61 69 6C Job:53 53 41 56 30 32 20 2D 20 53 61 75 76 65 67 61 72 64 65 20 56 65 65 61 6D 2D 43 6F 6D 70 6C E8 74 65 4C 65 20 74 72 61 76 61 69 6C 20 61 20 64 E9 6D 61 72 72 E9 2E
Wed May 18 01:04:03 2016 .1.3.6.1.4.1.1302.3.1.2.8.0.7 MINOR "Status Events" ssav02 - User advised of event: Backup Exec: Avertissement de travail
There associated to this :
EVENT onVmBackupCompleted .1.3.6.1.4.1.31023.1.1.1.0.2 "Status Events" Normal
FORMAT $*
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $2 "Backup Veeam" 0 "$2 : $4 ($5)"
SDESC
This trap is sent on vm backup/replica completed.
Variables:
1: backupJobName
2: vmName
3: sourceHostName
4: vmBackupResult
5: vmBackupComment
EDESC
EVENT jobStarted .1.3.6.1.4.1.1302.3.1.2.8.0.5 "Status Events" INFORMATIONAL
FORMAT User advised of event: $1 Job:$3 $4
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r "Sauvegarde ${3}" 0 "User advised of event: $1 Job:$3 $4"
SDESC
The Job has started.
Variables:
1: messageText
2: serverName
3: jobName
4: additionalText
EDESC
EVENT jobWarning .1.3.6.1.4.1.1302.3.1.2.8.0.7 "Status Events" MINOR
FORMAT User advised of event: $1
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 1 "User advised of event: $1"
SDESC
The job has a warning.
Variables:
1: messageText
EDESC
As you can see, for some trap, the message is not properly encoded, and the message generated is indescriptible.
So why is my message sometime Hex-string encoded ? How to fix this ?