[GH-ISSUE #106] Routine of RAM size evaluation not sufficient and might cause issues #542

New issue

Closed

opened 2026-03-11 11:51:53 +03:00 by kerem · 2 comments

kerem commented

2026-03-11 11:51:53 +03:00

Owner

Originally created by @luddinho on GitHub (Jun 30, 2023).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/106

Environment

script version: v3.0.56
OS: DSM 7.2
Device: 1817+
RAM: 2x 8GB

Problem description

The evaluation of RAM size might cause issues because the condition of the grep command for dmidecode is not clear enough.

Example:
On my system the command dmidecode -t memory | grep "[Ss]ize" will return the following content.

Size: 8192 MB
Size: No Module Installed
Size: 8192 MB
Size: No Module Installed

Now you can imagine what will happen with the variables $ramsize and $bytes when evaluating with awk.

ramsize=$(printf %s "${array[num]}" | awk '{print $2}')
bytes=$(printf %s "${array[num]}" | awk '{print $3}')

The result is:

ramsize: 8192
bytes: MB
ramsize: No
bytes: Module
ramsize: 8192
bytes: MB
ramsize: No
bytes: Module

At the end of the loop we will have fortunately the correct numeric value for the variable $ramtotal. But the unit for $bytes is inconsitent.

ramtotal: 16384
bytes: Module

Proposed solution

My proposal is to make the grep command with an extended regular expression much more precise that will return only the size with numeric values and additionally with a valid unit either MB or GB as postfix at the end of the line.

#Proposal
dmidecode -t memory | grep -E "[Ss]ize: [0-9]+ [MG]{1}[B]{1}$"

# Return
Size: 8192 MB
Size: 8192 MB

I haven´t checked other systems yet, but it could also lead to an error in the calculation of $ramtotal size.
Please have a look and check if the improvement can be implemented.

Originally created by @luddinho on GitHub (Jun 30, 2023). Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/106 # Environment script version: v3.0.56 OS: DSM 7.2 Device: 1817+ RAM: 2x 8GB # Problem description The evaluation of RAM size might cause issues because the condition of the grep command for `dmidecode` is not clear enough. Example: On my system the command `dmidecode -t memory | grep "[Ss]ize"` will return the following content. ``` Size: 8192 MB Size: No Module Installed Size: 8192 MB Size: No Module Installed ``` Now you can imagine what will happen with the variables $ramsize and $bytes when evaluating with awk. ``` ramsize=$(printf %s "${array[num]}" | awk '{print $2}') bytes=$(printf %s "${array[num]}" | awk '{print $3}') ``` The result is: ``` ramsize: 8192 bytes: MB ramsize: No bytes: Module ramsize: 8192 bytes: MB ramsize: No bytes: Module ``` At the end of the loop we will have fortunately the correct numeric value for the variable $ramtotal. But the unit for $bytes is inconsitent. ``` ramtotal: 16384 bytes: Module ``` # Proposed solution My proposal is to make the grep command with an extended regular expression much more precise that will return only the size with numeric values and additionally with a valid unit either MB or GB as postfix at the end of the line. ``` #Proposal dmidecode -t memory | grep -E "[Ss]ize: [0-9]+ [MG]{1}[B]{1}$" # Return Size: 8192 MB Size: 8192 MB ``` I haven´t checked other systems yet, but it could also lead to an error in the calculation of $ramtotal size. Please have a look and check if the improvement can be implemented.

kerem closed this issue

2026-03-11 11:51:59 +03:00

kerem commented

2026-03-11 11:52:04 +03:00

Author

Owner

@007revad commented on GitHub (Jun 30, 2023):

Nicely formatted issue, and nice solution. Thank you.

@007revad commented on GitHub (Jun 30, 2023): Nicely formatted issue, and nice solution. Thank you.

kerem commented

2026-03-11 11:52:09 +03:00

Author

Owner

@luddinho commented on GitHub (Jun 30, 2023):

From a code review so far, it looks pretty good. I think this is fine now.

Thanks for the fix.

@luddinho commented on GitHub (Jun 30, 2023): From a code review so far, it looks pretty good. I think this is fine now. Thanks for the fix.

kerem referenced this issue

2026-03-12 17:54:04 +03:00

[PR #542] [MERGED] v3.6.116 #1152

kerem referenced this issue

2026-03-12 17:54:04 +03:00

[PR #551] [MERGED] sync from main #1153