memory_map does not give expected results in Linux - osquery

The query .all memory_map on the Linux system gives unexpected results as start memory location = 0x00000000 as well as end memory location = 0x00000000 for all the attributes. Does it just seem weird?
Operating System: Kali Linux
osquery version: 4.0.2 (Current)
I've tried searching on the issues at osquery/issues/
The exact replication of the code on the CLI is:
osqueryi
.all memory_map
which gives the same result as:
osqueryi
SELECT * FROM memory_map
The output of osqueryi is nothing but a message showing that it is using a virtual database as follows.
Using a virtual database. Need help, type '.help'
And the output of .all memory_map is as follows:
+-------------------------------+------------+-------------+
| name | start | end |
+-------------------------------+------------+-------------+
| Reserved | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| PCI Bus 0000:00 | 0x00000000 | 0x00000000 |
| Video ROM | 0x00000000 | 0x00000000 |
| Adapter ROM | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| System ROM | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| ACPI Non-volatile Storage | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| ACPI Non-volatile Storage | 0x00000000 | 0x00000000 |
| ACPI Tables | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| Graphics Stolen Memory | 0x00000000 | 0x00000000 |
| PCI Bus 0000:00 | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| PCI Bus 0000:01 | 0x00000000 | 0x00000000 |
| 0000:01:00.0 | 0x00000000 | 0x00000000 |
| 0000:01:00.0 | 0x00000000 | 0x00000000 |
| 0000:00:02.0 | 0x00000000 | 0x00000000 |
| PCI Bus 0000:01 | 0x00000000 | 0x00000000 |
| 0000:01:00.0 | 0x00000000 | 0x00000000 |
| PCI Bus 0000:03 | 0x00000000 | 0x00000000 |
| 0000:03:00.0 | 0x00000000 | 0x00000000 |
| iwlwifi | 0x00000000 | 0x00000000 |
| PCI Bus 0000:02 | 0x00000000 | 0x00000000 |
| 0000:02:00.1 | 0x00000000 | 0x00000000 |
| 0000:02:00.1 | 0x00000000 | 0x00000000 |
| r8169 | 0x00000000 | 0x00000000 |
| 0000:02:00.0 | 0x00000000 | 0x00000000 |
| rtsx_pci | 0x00000000 | 0x00000000 |
| 0000:02:00.0 | 0x00000000 | 0x00000000 |
| 0000:00:1f.3 | 0x00000000 | 0x00000000 |
| ICH HD audio | 0x00000000 | 0x00000000 |
| 0000:00:14.0 | 0x00000000 | 0x00000000 |
| xhci-hcd | 0x00000000 | 0x00000000 |
| intel_xhci_usb_sw | 0x00000000 | 0x00000000 |
| 0000:00:1f.3 | 0x00000000 | 0x00000000 |
| ICH HD audio | 0x00000000 | 0x00000000 |
| 0000:00:1f.2 | 0x00000000 | 0x00000000 |
| 0000:00:17.0 | 0x00000000 | 0x00000000 |
| ahci | 0x00000000 | 0x00000000 |
| 0000:00:15.0 | 0x00000000 | 0x00000000 |
| lpss_dev | 0x00000000 | 0x00000000 |
| i2c_designware.0 | 0x00000000 | 0x00000000 |
| lpss_priv | 0x00000000 | 0x00000000 |
| idma64.0 | 0x00000000 | 0x00000000 |
| idma64.0 | 0x00000000 | 0x00000000 |
| 0000:00:15.1 | 0x00000000 | 0x00000000 |
| lpss_dev | 0x00000000 | 0x00000000 |
| i2c_designware.1 | 0x00000000 | 0x00000000 |
| lpss_priv | 0x00000000 | 0x00000000 |
| idma64.1 | 0x00000000 | 0x00000000 |
| idma64.1 | 0x00000000 | 0x00000000 |
| 0000:00:16.0 | 0x00000000 | 0x00000000 |
| mei_me | 0x00000000 | 0x00000000 |
| 0000:00:17.0 | 0x00000000 | 0x00000000 |
| ahci | 0x00000000 | 0x00000000 |
| 0000:00:1f.4 | 0x00000000 | 0x00000000 |
| 0000:00:17.0 | 0x00000000 | 0x00000000 |
| ahci | 0x00000000 | 0x00000000 |
| 0000:00:02.0 | 0x00000000 | 0x00000000 |
| PCI MMCONFIG 0000 [bus 00-ff] | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| PCI Bus 0000:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| INT344B:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| iTCO_wdt | 0x00000000 | 0x00000000 |
| iTCO_wdt | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| pnp 00:00 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| IOAPIC 0 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| HPET 0 | 0x00000000 | 0x00000000 |
| PNP0103:00 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| MSFT0101:00 | 0x00000000 | 0x00000000 |
| MSFT0101:00 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| dmar0 | 0x00000000 | 0x00000000 |
| dmar1 | 0x00000000 | 0x00000000 |
| Local APIC | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| pnp 00:07 | 0x00000000 | 0x00000000 |
| INT0800:00 | 0x00000000 | 0x00000000 |
| Reserved | 0x00000000 | 0x00000000 |
| System RAM | 0x00000000 | 0x00000000 |
| Kernel code | 0x00000000 | 0x00000000 |
| Kernel data | 0x00000000 | 0x00000000 |
| Kernel bss | 0x00000000 | 0x00000000 |
| RAM buffer | 0x00000000 | 0x00000000 |
+-------------------------------+------------+-------------+


The memory_map table needs root permissions. Are you using root for the test?
(I can replicate that if I don't run with elevated permissions)


Update: Yes, I was using the root user. I eventually changed my system to Kubuntu 19.04 and there it works like a charm.

Related

How to get associated timestamp with time_bucket_gapfill and MIN?

I have a hypertable, sensor_data:
client_id | name | profile_id | time | exc | sensor_id | unit | val | valid
-----------+------+------------+----------------------------+-----+-----------+------+------+-------
tony | temp | 12345 | 2023-02-14 15:29:11.610973 | 0 | 12345 | c | 37.5 | t
tony | temp | 12345 | 2023-02-14 15:29:37.2002 | 0 | 12345 | c | 38.5 | t
tony | temp | 12345 | 2023-02-14 15:30:34.591719 | 0 | 12345 | c | 39.5 | t
tony | temp | 12345 | 2023-02-14 15:31:04.339514 | 0 | 12345 | c | 37.5 | t
tony | temp | 12345 | 2023-02-14 15:31:22.18442 | 0 | 12345 | c | 38.5 | t
tony | temp | 12345 | 2023-02-14 15:31:39.362446 | 0 | 12345 | c | 39.5 | t
tony | temp | 12345 | 2023-02-14 15:32:13.574646 | 0 | 12345 | c | 37.5 | t
tony | temp | 12345 | 2023-02-14 15:32:41.298819 | 0 | 12345 | c | 38.5 | t
tony | temp | 12345 | 2023-02-14 15:32:59.524967 | 0 | 12345 | c | 39.5 | t
tony | temp | 12345 | 2023-02-14 15:33:15.794619 | 0 | 12345 | c | 37.5 | t
tony | temp | 12345 | 2023-02-14 15:34:21.144824 | 0 | 12345 | c | 38.5 | t
tony | temp | 12345 | 2023-02-14 15:34:46.447752 | 0 | 12345 | c | 39.5 | t
I need to get the minimum value from the buckets with time_bucket_gapfill, but I want to see the associated time for the minimum value. For example:
minbucket | minval | time
---------------------+---------+----------------------------
2023-02-14 15:29:00 | 37.5 | 2023-02-14 15:29:11.610973
2023-02-14 15:29:30 | 38.5 | 2023-02-14 15:29:37.2002
2023-02-14 15:30:00 | |
2023-02-14 15:30:30 | 39.5 | 2023-02-14 15:30:34.591719
2023-02-14 15:31:00 | 37.5 | 2023-02-14 15:31:04.339514
2023-02-14 15:31:30 | 39.5 | 2023-02-14 15:31:39.362446
2023-02-14 15:32:00 | 37.5 | 2023-02-14 15:32:13.574646
2023-02-14 15:32:30 | 38.5 | 2023-02-14 15:32:41.298819
2023-02-14 15:33:00 | 37.5 | 2023-02-14 15:33:15.794619
2023-02-14 15:33:30 | |
2023-02-14 15:34:00 | 38.5 | 2023-02-14 15:34:21.144824
2023-02-14 15:34:30 | 39.5 | 2023-02-14 15:34:46.447752
I tried adding time to the group by, but that simply returned a Cartesian mess.
Here is the gapfill that produced the above data. I added the associated timestamps by hand.
select time_bucket_gapfill(make_interval(secs=>30), time, start=>'2023-02-14 15:29:11.610973', finish=>'2023-02-14 15:34:46.447752') as minbucket, min(val) as minval from sensor_data group by minbucket;

This is ugly, but it seems to work:
select gf.minbucket, gf.minval, av.mintime
from
(select time_bucket_gapfill(make_interval(secs=>30), time, start=>'2023-02-14 15:29:11.610973', finish=>'2023-02-14 15:34:46.447752') as minbucket, min(val) as minval from reading_parameter group by minbucket) gf
LEFT OUTER JOIN
(select time_bucket_gapfill(make_interval(secs=>30), time, start=>'2023-02-14 15:29:11.610973', finish=>'2023-02-14 15:34:46.447752') as minbucket, time as mintime, val as bval from reading_parameter) as av
on av.minbucket=gf.minbucket AND av.bval=gf.minval
order by gf.minbucket;

Is it possible to conditionally pivot columns of different data types in Oracle?

Using Oracle 12c. I have a query that returns all the data I need, however it is split across multiple rows. I'm trying to use pivot to consolidate the data from n rows into 1 row, transposing n unique value sets from 2 columns into n columns, conditionally choosing which column from a set of columns to use the value from for each of the n transposed columns.
I'm struggling to find out if this is possible, or if it can't be done.
Following is a simplified example of what the query returns:
| ID | Inst_Created | Inst_Modified | Inst_Group | Inst_Prop | VAL_INT | VAL_REAL | VAL_STR |
+----+--------------+---------------+------------+-----------+---------+----------+---------+
| 01 | 1571954537 | 1571954537 | GenGroup1 | IntProp1 | 0 | (null) | (null) |
| 01 | 1571954537 | 1571954537 | GenGroup1 | RealProp2 | (null) | 12.34567 | (null) |
| 01 | 1571954537 | 1571954537 | GenGroup1 | RealProp3 | (null) | 123.4567 | (null) |
| 01 | 1571954537 | 1571954537 | GenGroup1 | StrProp4 | (null) | (null) | dirpath |
| 01 | 1571954537 | 1577754537 | GenGroup2 | IntProp5 | 1337 | (null) | (null) |
| 01 | 1571954537 | 1577754537 | GenGroup2 | RealProp6 | (null) | 13.37 | (null) |
| 01 | 1570054537 | 1570854537 | GenGroup3 | StrProp7 | (null) | (null) | testing |
| 01 | 1570054537 | 1570854537 | GenGroup3 | StrProp8 | (null) | (null) | valid |
| 02 | 1571954540 | 1571954540 | GenGroup1 | IntProp1 | 1 | (null) | (null) |
| 02 | 1571954540 | 1571954540 | GenGroup1 | RealProp2 | (null) | 12.34568 | (null) |
| 02 | 1571954540 | 1571954540 | GenGroup1 | RealProp3 | (null) | 123.4568 | (null) |
| 02 | 1571954540 | 1571954540 | GenGroup1 | StrProp4 | (null) | (null) | dirpat2 |
| 02 | 1571954540 | 1577754540 | GenGroup2 | IntProp5 | 1338 | (null) | (null) |
| 02 | 1571954540 | 1577754540 | GenGroup2 | RealProp6 | (null) | 13.38 | (null) |
| 02 | 1570054540 | 1570854540 | GenGroup3 | StrProp7 | (null) | (null) | testin2 |
| 02 | 1570054540 | 1570854540 | GenGroup3 | StrProp8 | (null) | (null) | valid2 |
+----+--------------+---------------+------------+-----------+---------+----------+---------+
The Inst_Created and Inst_Modified columns are mock epoch timestamps. The VAL_INT, VAL_REAL, and VAL_STR columns are NUMBER(38,0), FLOAT, and VARCHAR2(1024) data types respectively. Only one of the three VAL_* columns will be non-null for any given row; You can know which one of the three it'll be by the Inst_Group, Inst_Prop columns.
Following is a simplified example of what I'm trying to produce by using pivot:
| ID | Earliest_Created | Latest_Modified | G1P1_Int | G1P2_Real | G1P3_Real | G1P4_Str | G2P5_Int | G2P6_Real | G3P7_Str | G3P8_Str |
+----+------------------+-----------------+----------+-----------+-----------+----------+----------+-----------+----------+----------+
| 01 | 1570054537 | 1577754537 | 0 | 12.34567 | 123.4567 | dirpath | 1337 | 13.37 | testing | valid |
| 02 | 1570054540 | 1579954540 | 1 | 12.34568 | 123.4568 | dirpat2 | 1338 | 13.38 | testin2 | valid2 |
+----+------------------+-----------------+----------+-----------+-----------+----------+----------+-----------+----------+----------+
I've figured out how to use the pivot_for_clause and pivot_in_clause clauses to turn the (Inst_Group, Inst_Prop) values into columns while renaming the column. What I'm struggling to figure out is how to get the values into the transposed columns, with them being the right data type.
I had previously attempted to use the LISTAGG function in the query, casting all the VAL_* values to varchar2, so that there was only one column for VAL values. I gave up on that method due to the problems in trying to get each transposed column to be the correct original data type, and due to the performance hit all of that seemed to be causing.

You can achieve it using conditional aggreagation:
Select ID, EARLIEST_CREATED, LATEST_MODIFIED,
MAX(CASE WHEN INST_GROUP = 'GenGroup1' and INST_PROP1 = 'IntProp1' THEN VAL_INT END) AS G1P1_INT,
MAX(CASE WHEN INST_GROUP = 'GenGroup1' and INST_PROP1 = 'RealProp2' THEN VAL_REAL END) AS G1P2_REAL,
...
..
.
From your_table
Group by ID, EARLIEST_CREATED, LATEST_MODIFIED;
Cheers!!

Error converting data type nvarchar to numeric but I have no idea why

I ran a query I created but I am getting an "Error converting data type nvarchar to numeric" error along with "Warning: Null value is eliminated by an aggregate or other SET operation." but I have no idea why as I am not converting anything.
Here is my query:
SELECT DISTINCT TOP 1000
O.Date_Entered
,O.Company_Code
,O.Division_Code
,O.Customer_Purchase_Order_Number
,O.Control_Number
,O.Customer_Number
,P.PickTicket_Number
,sh.PACKSLIP
,Accellos_Download
,Accellos_Allocated
,Accellos_Waved
,Accellos_Label
,Accellos_Last_Pick
,Accellos_Rating
,Accellos_Shipped
,Accellos_Upload
FROM [JMNYC-AMTDB].[AMTPLUS].[dbo].Orders o (nolock)
LEFT JOIN [JMNYC-AMTDB].[AMTPLUS].[dbo].PickTickets P (nolock)
on O.Company_Code = P.Company_Code
and O.Division_Code = P.Division_Code
and O.Control_Number = P.Control_Number
LEFT JOIN [JMDNJ-ACCELSQL].[A1WAREHOUSE].[dbo].SHIPHIST sh (nolock) ON o.Customer_Purchase_Order_Number = sh.cust_po
LEFT JOIN (
SELECT
Packslip
,max( case when Action like 'DNLOAD' then Date_Time end) as Accellos_Download
,max( case when Action like 'ALLOC' then Date_Time end) as Accellos_Allocated
,max( case when Action like 'WAVEORDER' then Date_Time end) as Accellos_Waved
,max( case when Action like 'NEWLABEL' then Date_Time end) as Accellos_Label
,max( case when Action like 'EOL_LSTP' then Date_Time end) as Accellos_Last_Pick
,max( case when Action like 'RATED' then Date_Time end) as Accellos_Rating
,max( case when Action like 'SHIPPED' then Date_Time end) as Accellos_Shipped
,max( case when Action like 'UPLOAD' then Date_Time end) as Accellos_Upload
FROM(
SELECT DISTINCT
Packslip
,Date_Time
,Action
from [JMDNJ-ACCELSQL].[A1Warehouse].[dbo].[RF_LOG2] RL (nolock)
)RLTS
group by Packslip
)RLTSS on Coalesce(sh.PACKSLIP, P.pickticket_number) = RLTSS.PACKSLIP
Here is a sample of the RF_LOG2 Table
+--------------------------------------+----------+----------+---------------------------------------------------------------------------------------------------------+--------+----------+----------+----------+----------+-----------+---------------------+----------------------+----------------------+--------------------+------------+----------+--------+--------+----------+------------------+------------+----------+----------+
| ROWID | PACKSLIP | BINLABEL | EXTENDED | TERMID | USERID | ACTION | QUANTITY | Q_SCALER | TOTLABEL | REFERENCE2 | REFERENCE3 | DATE_TIME | DATE_CREAT | CLIENTNAME | TENANTID | PO_NUM | SERIAL | LOCATION | LICENSE_PLATE | PURGE_FLAG | PACKSIZE | UPLOADED |
+--------------------------------------+----------+----------+---------------------------------------------------------------------------------------------------------+--------+----------+----------+----------+----------+-----------+---------------------+----------------------+----------------------+--------------------+------------+----------+--------+--------+----------+------------------+------------+----------+----------+
| BC5A92B0-F347-4E27-80C5-49798E1B6B75 | 90214801 | PICK | | 0 | | DNLOAD | 0.000000 | 0 | | E. Keith DuBose | l:1 u:1 | 20190726 13:15:29.87 | 0x00000000207E9F1E | 09 | | | | | | 1 | 1.000000 | 0 |
| 3564B24F-1AA9-42A4-83A4-D14151395CED | 90214801 | | | 0 | jsac | ALLOCORD | 0.000000 | 0 | | Allocated | READY TO WAVE | 20190726 13:25:54.51 | 0x00000000207E4672 | 09 | | | | | | 1 | 1.000000 | 0 |
| 0E5B3952-2BD4-4035-A645-1C024B8D3F10 | 90214801 | | | 0 | jsac | ALLOC | 0.000000 | 0 | | Release SWOG | | 20190726 13:25:54.54 | 0x00000000207F14C6 | 09 | | | | | | 1 | 1.000000 | 0 |
| 09575559-EB27-4CDB-8B35-56F741F779E1 | 90214801 | | | 0 | jsac | WAVEORDR | 0.000000 | 0 | | Wave:2392 | RF Picking | 20190726 15:05:31.71 | 0x00000000207EFE60 | 09 | | | | | | 1 | 1.000000 | 0 |
| 61B21B11-D638-4AA2-A94A-25B54650EBAD | 90214801 | | | 0 | | EOL_PRNT | 0.000000 | 0 | | New Carton | 00008139850296299650 | 20190726 15:06:03.79 | 0x00000000207E5A7D | 09 | | | | | | 1 | 1.000000 | 0 |
| 7B46FD91-A30D-4D92-A9E9-6024630D2710 | 90214801 | | | 0 | RFBASE | NEWLABEL | 0.000000 | 0 | 109629965 | 029629965 | | 20190726 15:06:03.80 | 0x00000000207E480E | 09 | | | | | | 1 | 1.000000 | 0 |
| 042D7D42-1D08-4926-AF5B-005868924302 | 90214801 | 3F88082A | 910B2307NSZ99000 /09 | 0 | LSAB | PICK_LP | 1.000000 | 1 | 109629965 | LP picking | | 20190726 15:55:58.92 | 0x00000000207F04F4 | 09 | | | | | 910B2307NSZ99000 | 1 | 1.000000 | 0 |
| 21711DE4-6119-47C0-B3F0-1A0AB816A679 | 90214801 | 3F88082A | 910B2307NSZ99000 /09 | 0 | LSAB | MOVE-OUT | 1.000000 | -1 | | 1 Packs of 1.000000 | via PICKING | 20190726 15:55:58.94 | 0x00000000207E32CC | 09 | | | | | | 1 | 1.000000 | 0 |
| E0D5C819-DC3C-4E21-9857-25476432A057 | 90214801 | 3F88082A | 910B2307NSZ99000 /09 | 0 | LSAB | PICKDETL | 1.000000 | -1 | 109629965 | | | 20190726 15:55:58.95 | 0x00000000207E239A | 09 | | | | | | 1 | 1.000000 | 0 |
| 20D981C1-CE83-459F-9D7A-1784CC215856 | 90214801 | | | 0 | LSAB | EOL_LSCP | 0.000000 | 0 | | Last Pick In Carton | 00008139850296299650 | 20190726 15:55:58.97 | 0x00000000207E07FE | 09 | | | | | | 1 | 1.000000 | 0 |
| CDBCBD5B-9DC7-4FE5-91C9-7C409EA4C2D9 | 90214801 | | | 0 | LSAB | PICKORDR | 0.000000 | 0 | | | | 20190726 15:55:58.97 | 0x00000000207F1CEE | 09 | | | | | | 1 | 1.000000 | 0 |
| DD637317-640E-4A8D-A8DB-9C2C587BA217 | 90214801 | 3F88082A | 910B2307NSZ99000 /09 | 0 | LSAB | PICKLINE | 1.000000 | -1 | | 1 | | 20190726 15:55:58.97 | 0x00000000207E8F55 | 09 | | | | | | 1 | 1.000000 | 0 |
| EE4D734C-8CCE-4C73-B133-C024D79A6054 | 90214801 | | | 0 | LSAB | EOL_LSTP | 0.000000 | 0 | | LAST PICK COMPLETED | 2 | 20190726 15:55:58.97 | 0x00000000207F516E | 09 | | | | | | 1 | 1.000000 | 0 |
| 06204BC1-87B1-4340-9712-C8996388B550 | 90214801 | | | 0 | BACKGRND | RATED | 0.000000 | 0 | 109629965 | 109629965 ACT99 | SHP1563345 | 20190729 08:30:39.86 | 0x000000002089F080 | 09 | | | | | | 1 | 1.000000 | 0 |
| 48759371-8B78-4901-8BE4-749FA55E1D40 | 90214801 | | | 0 | BACKGRND | EOL_SSYS | 0.000000 | 0 | | ShipSys Confirm | | 20190729 08:30:39.89 | 0x0000000020896EF1 | 09 | | | | | | 1 | 1.000000 | 0 |
| 904BF8C6-794D-4288-A594-22BA93A31095 | 90214801 | | | 0 | BACKGRND | SHIPPED | 0.000000 | 0 | | USPS PM | SHP1563345 | 20190729 08:30:39.90 | 0x000000002087F9F3 | 09 | | | | | | 1 | 1.000000 | 0 |
| ECA102C8-B7C4-46D3-A844-FBD0CFE79413 | 90214801 | | | 0 | sdob | SUSPEND | 0.000000 | 0 | | | | 20190729 09:45:40.12 | 0x00000000208922D8 | 09 | | | | | | 1 | 1.000000 | 0 |
| 867A7B87-5AB2-4EE7-8FDC-7175D406C0F0 | 90214801 | | | 0 | sdob | UNSUSPND | 0.000000 | 0 | | | | 20190729 10:07:56.88 | 0x00000000208A0AF5 | 09 | | | | | | 1 | 1.000000 | 0 |
| E5FB157B-9837-4DA8-B5D0-9A605603FD60 | 90214801 | | | 0 | sdob | SHIPCOMP | 0.000000 | 0 | | | ship_order() | 20190729 11:42:20.30 | 0x000000002089D1FD | 09 | | | | | | 1 | 1.000000 | 0 |
| 37D4B782-1184-4F91-913B-F1BA251740DF | 90214801 | | | 0 | sdob | SHIPPED | 0.000000 | 0 | | USPS PM | SHP1563345 | 20190729 11:42:20.32 | 0x000000002088482F | 09 | | | | | | 1 | 1.000000 | 0 |
| 4FDE75F7-D98B-451E-A106-0C9F29BADEE1 | 90214801 | | | 0 | sdob | EOL_EXTN | 0.000000 | 0 | | External Process | | 20190729 11:42:20.33 | 0x0000000020897E4A | 09 | | | | | | 1 | 1.000000 | 0 |
| C41D73C8-385A-4547-A684-7CEA1B7CE9DB | 90214801 | PICK | | 0 | C# | UPLOAD | 0.000000 | 0 | | E. Keith DuBose | | 20190729 11:43:45.66 | 0x00000000208A1D2F | | | | | | | 1 | 1.000000 | 0 |
+--------------------------------------+----------+----------+---------------------------------------------------------------------------------------------------------+--------+----------+----------+----------+----------+-----------+---------------------+----------------------+----------------------+--------------------+------------+----------+--------+--------+----------+------------------+------------+----------+----------+
What I am trying to do is to get the timestamp for each part of the order. So when it was created, when it was picked, and so on. I want this information to be displayed horizontally, per order. Also, it only crashed after running for like 5 minutes.

The warning Warning: Null value is eliminated by an aggregate or other SET operation happen because of the value of Date_Time that you do in max() containing NULL value.
For the error, I'm afraid that that causes from Coalesce(sh.PACKSLIP, P.pickticket_number). You should check the type and convert one of them to have the same type as another. From the hint from the table, you attached they both should be the numeric value.

To avoid the warning you can use below option.
SET ANSI_WARNINGS OFF

Analyzing ELF memory layout

I was analyzing an ELF Executable with readelf and getting the following Program and header.
|Type | Offset | VirtAddr | PhysAddr | FileSiz | MemSiz | Flg | Align | size | start addr | end addr |
|PHDR | 0x000034 | 0x08048034 | 0x08048034 | 0x00120 | 0x00120 | R E | 0x4 | 288 | 52 | 340 |
|INTERP | 0x000154 | 0x08048154 | 0x08048154 | 0x00013 | 0x00013 | R | 0x1 | 19 | 340 | 359 |
|LOAD | 0x000000 | 0x08048000 | 0x08048000 | 0x00600 | 0x00600 | RE | 0x1000 | 1536 | 0 | 1536 |
|LOAD | 0x000f0c | 0x08049f0c | 0x08049f0c | 0x0010c | 0x00114 | RW | 0x1000 | 276 | 3852 | 4128 |
|DYNAMIC | 0x000f14 | 0x08049f14 | 0x08049f14 | 0x000e8 | 0x000e8 | RW | 0x4 | 232 | 3860 | 4092 |
|NOTE | 0x000168 | 0x08048168 | 0x08048168 | 0x00044 | 0x00044 | R | 0x4 | 68 | 360 | 428 |
|GNU_EH_FRAME | 0x0004c4 | 0x080484c4 | 0x080484c4 | 0x0003c | 0x0003c | R | 0x4 | 60 | 1220 | 1280 |
|GNU_STACK | 0x000000 | 0x00000000 | 0x00000000 | 0x00000 | 0x00000 | RW | 0x10 | | | |
|GNU_RELRO | 0x000f0c | 0x08049f0c | 0x08049f0c | 0x000f4 | 0x000f4 | R | 0x1 | 244 | 3852 | 4096 |
1). Why is GNU_STACK at Program header table doesn't have a size or start addr?
2). At layout why memory position from 1536 to 3852 (2316 bytes) have no information? What this space is used for?
3). What changes to this format are needed to add extra text section?

Why ignite does not load all records into cache when server node count increased?

I have developed ignite sample data grid application with third party persistence. I have an entity named UserInfo. I have generated 3602000 records and added them into database. I have 64 GB ram on my machine. I am running n server nodes and after cluster initialized run a client node to trigger loading caches. When I run one or two server nodes and then load cache everything is fine. All records are loaded into the cache. When I run 4 server nodes approximately half of the records are loaded into the cache. There are a lot of free memory on the machine. I have created a github repo for sample application https://github.com/serdroid/userinfo .
Below free command output and ignitevisorcmd output for both cases.
before starting servers
free --giga
total used free shared buff/cache available
Mem: 65 8 52 0 4 56
2 server nodes running with -Xmx4G
Loaded 3602000 keys with backups in 255911ms.
Free memory
free --giga
total used free shared buff/cache available
Mem: 65 20 38 0 6 45
Cache details
Nodes for: info.serdroid.userinfo.grid.model.UserInfo(#c0)
+================================================================================================================+
| Node ID8(#), IP | CPUs | Heap Used | CPU Load | Up Time | Size | Hi/Mi/Rd/Wr |
+================================================================================================================+
| 800C684F(#n1), 10.251.74.157 | 4 | 87.97 % | 0.40 % | 00:13:07.851 | Total: 1837114 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 1837114 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+------------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 40FD7F83(#n0), 10.251.74.157 | 4 | 86.30 % | 0.40 % | 00:13:25.431 | Total: 1764886 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 1764886 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+----------------------------------------------------------------------------------------------------------------+
4 server nodes running with -Xmx4G
Loaded 1805474 keys with backups in 98203ms.
Free memory
free --giga
total used free shared buff/cache available
Mem: 65 23 35 0 6 41
Cache details
Nodes for: info.serdroid.userinfo.grid.model.UserInfo(#c0)
+================================================================================================================+
| Node ID8(#), IP | CPUs | Heap Used | CPU Load | Up Time | Size | Hi/Mi/Rd/Wr |
+================================================================================================================+
| 9B36B2E9(#n2), 10.251.74.157 | 4 | 65.52 % | 0.27 % | 00:14:58.116 | Total: 534454 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 534454 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+------------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 1222A1A4(#n0), 10.251.74.157 | 4 | 39.65 % | 2.33 % | 00:15:06.421 | Total: 389344 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 389344 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+------------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 8699AB89(#n1), 10.251.74.157 | 4 | 62.77 % | 0.23 % | 00:15:01.325 | Total: 441069 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 441069 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+------------------------------+------+-----------+----------+--------------+----------------------+-------------+
| 8B43AF4C(#n3), 10.251.74.157 | 4 | 65.44 % | 1.73 % | 00:14:55.624 | Total: 440607 | Hi: 0 |
| | | | | | Heap: 0 | Mi: 0 |
| | | | | | Off-Heap: 440607 | Rd: 0 |
| | | | | | Off-Heap Memory: 0 | Wr: 0 |
+----------------------------------------------------------------------------------------------------------------+

Apache Ignite uses off-heap memory to store your data. Please configure (enlarge) data region as it is described at https://apacheignite.readme.io/docs/memory-configuration.
Apache Ignite works in a Lazy way for loading data into memory from a store by design.
You can force data reload by Cache.loadCache(null) manually, or you can use EventType.EVT_NODE_JOINED local event as a trigger. Please see https://apacheignite.readme.io/docs/events for more details.