my snmp version is 5.7.2, after i install it on ubuntu and try to get disk space like this:
cloud#cloud:~/snmp/net-snmp-5.7.2$ snmpwalk -v 2c -c public 10.0.0.125 .1.3.6.1.4.1.2021.9.1.11
UCD-SNMP-MIB::dskTotalLow = No Such Object available on this agent at this OID
when i changed the mib, then get the right answer as follows:
cloud#cloud:~/snmp/net-snmp-5.7.2$ snmpwalk -v 2c -c public 10.0.0.125 .1.3.6.1.4.1.2021.9.1.6
UCD-SNMP-MIB::dskTotal.1 = INTEGER: 14332332
UCD-SNMP-MIB::dskTotal.2 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.3 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.4 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.5 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.6 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.7 = INTEGER: 500708
UCD-SNMP-MIB::dskTotal.8 = INTEGER: 0
UCD-SNMP-MIB::dskTotal.9 = INTEGER: 203908
UCD-SNMP-MIB::dskTotal.10 = INTEGER: 5120
UCD-SNMP-MIB::dskTotal.11 = INTEGER: 509768
UCD-SNMP-MIB::dskTotal.12 = INTEGER: 233191
now, please give me some advice to get the dskTotalLow value, to solve the wrong value for large disk space, thanks so much.
Check your snmpd.conf settings regarding regarding Disk Usage Monitoring. Here is an extract from "man snmpd.conf".
Disk Usage Monitoring
This requires that the agent was built with support for the ucd-snmp/disk module (which is included as part of the default build con-
figuration).
disk PATH [ MINSPACE | MINPERCENT% ]
monitors the disk mounted at PATH for available disk space.
The minimum threshold can either be specified in kB (MINSPACE) or as a percentage of the total disk (MINPERCENT% with a ’%’
character), defaulting to 100kB if neither are specified. If the free disk space falls below this threshold, then the corre-
sponding dskErrorFlag instance will be set to 1, and a suitable description message reported via the dskErrorMsg instance.
Note: This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
includeAllDisks MINPERCENT%
configures monitoring of all disks found on the system, using the specified (percentage) threshold. The threshold for indi-
vidual disks can be adjusted using suitable disk directives (which can come either before or after the includeAllDisks direc-
tive).
Note: Whether disk directives appears before or after includeAllDisks may affect the indexing of the dskTable.
Only one includeAllDisks directive should be specified - any subsequent copies will be ignored.
The list of mounted disks will be determined when the agent starts using the setmntent(3) and getmntent(3), or fopen(3) and
getmntent(3), or setfsent(3) and getfsent(3) system calls. If none of the above system calls are available then the root
partition "/" (which is assumed to exist on any UNIX based system) will be monitored. Disks mounted after the agent has
started will not be monitored.
If neither any disk directives or includeAllDisks are defined, then walking the dskTable will fail (noSuchObject).
Related
What are some (reliable) tests to find the disk a certain partition is on and put that result into a variable?
For example, output of lsblk:
...
sda 8:0 0 9.1T 0 disk
└─sda1 8:1 0 9.1T 0 part /foopath
...
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /barpath
└─mmcblk0p2 179:2 0 29.5G 0 part /foobarpath
If partition="/dev/mmcblk0p2", how can I put mmcblk0 as the disk it is a part of into a variable? Or similarly, if partition="/dev/sda1", how to put sda as the disk it is a part of into a variable?
disk=${partition::-1} seemed to be a hack until I encountered partitions such as mmcblk0p1, hence the request for a more reliable test...
The purpose of isolating the disk and using variable is to pass it to smartctl -n standby /dev/sda to find if disk is currently spinning, etc.
Operating environment is Linux Mint 19.3 and Ubuntu 20.
Any ideas?
Thanks to #KamilCuk and #don_crissti ;)
"Print just the parent device" using lsblk
#!/bin/bash
partition="/dev/sda1"
disk="$(lsblk -no pkname "${partition}")"
> size /bin/ls
__TEXT __DATA __OBJC others dec hex
20480 4096 0 4294983680 4295008256 10000a000
How could it be that ls is 4GB? Is size not meant to be used on executables? I have 4GB ram, so is it just showing me the amount memory it can use?
On macOS, 64-bit apps have a 4GB page zero, by default. Page zero is chunk of the address space starting at address 0 which allows no access. This is what causes access violations when a program dereferences a null pointer.
64-bit Mac programs use a 4GB page zero so that, should any valid pointer get accidentally truncated to 32 bits by a program bug (e.g. cast to int and back to a pointer), it will be invalid and cause a crash as soon as possible. That helps to find and fix such bugs.
The page zero segment in the Mach-O executable file doesn't actually use 4GB on disk. It's just a bit of metadata that tells the kernel and dynamic loader how much address space to reserve for it. It seems that size is including the virtual size of all segments, regardless of whether they take up space on disk or not.
Also, the page zero doesn't consume actual RAM when the program is loaded, either. Again, there's just some bookkeeping data to track the fact that the lower 4GB of the address space is reserved.
The size being reported for "others", 4294983680 bytes, is 0x100004000 in hex. That's the 4GB page zero (0x100000000) plus another 4 pages for some other segments.
You can use the -m option to size to get more detail:
$ size -m /bin/ls
Segment __PAGEZERO: 4294967296
Segment __TEXT: 20480
Section __text: 13599
Section __stubs: 456
Section __stub_helper: 776
Section __const: 504
Section __cstring: 1150
Section __unwind_info: 148
total 16633
Segment __DATA: 4096
Section __got: 40
Section __nl_symbol_ptr: 16
Section __la_symbol_ptr: 608
Section __const: 552
Section __data: 40
Section __bss: 224
Section __common: 140
total 1620
Segment __LINKEDIT: 16384
total 4295008256
You can also use the command otool -lV /bin/ls to see the loader commands of the executable, including the one establishing the __PAGEZERO segment.
The size command outputs information related to some binary executable and how it is running. It is not about the file. The 4Gb number might be (that is just my guess) related to the virtual address space needed to run it.
I don't have a MacOSX operating system (because it is proprietary and tied to hardware that I dislike and find too expensive). But on Linux (which is mostly POSIX, like MacOSX), size /bin/ls gives:
text data bss dec hex filename
124847 4672 4824 134343 20cc7 /bin/ls
while ls -l /bin/ls shows
-rwxr-xr-x 1 root root 138856 Feb 28 16:30 /bin/ls
Of course, when ls is running, it has some data (notably bss) which is not corresponding to a part of the executable
Try man size on your system to get an explanation. For Linux, see size(1) (it gives info about sections of an ELF executable) and ls(1) (it gives the file size).
On MacOSX, executables follow the Mach-O format.
On Linux, if you try size on a non-executable file such as /etc/passwd, you get
size: /etc/passwd: file format not recognized
and I guess that you should have some error message on MacOSX if you try that.
Think of size giving executable size information. The name is historical and a bit misleading.
I'm using Net-SNMP 5.5.0-2.x64 on Windows 10 1803. I'm trying to get SNMP values from a Ricoh printer. I've downloaded Printer-MIB and placed it in my C:\usr\share\snmp\mibs folder. I also downloaded and placed IANA-CHARSET-MIB and IANA-PRINTER-MIB. I also double checked snmp.conf to make sure they're in the right mibdirs folder.
I'm trying to access the value for black toner. I found some OIDs here, which I was trying to use for my example.
When I try to access the value for black toner:
snmpwalk -v 1 -c public -m Printer-MIB x.x.x.x 1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1
I get
SNMPv2-SMI::enterprises.367.3.2.1.2.24.1.1.5.1 = INTEGER: 80
I get the same result when I try -m ALL as well. Also if I try added Printer-MIB::printmib at the end, I get the same exact message.
When I try the command:
snmptranslate -IR -Td Printer-MIB::prtMarkerSuppliesLevel.1.1
I get
Printer-MIB::prtMarkerSuppliesLevel.1.1
prtMarkerSuppliesLevel OBJECT-TYPE
-- FROM Printer-MIB
SYNTAX Integer32 (-3..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The current level if this supply is a container; the remaining
space if this supply is a receptacle. If this supply
container/receptacle can reliably sense this value, the value
is reported by the printer and is read-only; otherwise, the
value may be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown. A value of (-3) means
that the printer knows that there is some supply/remaining
space, respectively."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) printmib(43) prtMarkerSupplies(11) prtMarkerSuppliesTable(1) prtMarkerSuppliesEntry(1) prtMarkerSuppliesLevel(9) 1 1 }
So doesn't that mean SNMP sees the file and can parse it?
Edit:
I was able to get the MIB file to work, but the OID values are confusing me. I ran snmpwalk -v 1 -c public x.x.x.x Printer-MIB::printmib and now the values with their MIB tags print. However, when I come across the value for black ink, the OID doesn't match the one I had found online, but they return the same value.
C:\usr\bin>snmpwalk -v 1 -c public x.x.x.x Printer-MIB::prtMarkerSuppliesLevel.1.1
Printer-MIB::prtMarkerSuppliesLevel.1.1 = INTEGER: 80
and
C:\usr\bin>snmpwalk -v 1 -c public x.x.x.x 1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1 Printer-MIB::printmib
SNMPv2-SMI::enterprises.367.3.2.1.2.24.1.1.5.1 = INTEGER: 80
If I run snmptranslate, I get a completely different OID than the one I had been using before:
C:\usr\bin>snmptranslate -On Printer-MIB::prtMarkerSuppliesLevel.1.1
.1.3.6.1.2.1.43.11.1.1.9.1.1
Not sure why the OID I found online works to retrieve the value, but not to work with the MIB file. Some sort of mix between proprietary and public MIB data?
Try the right OID
snmpwalk ... 1.3.6.1.2.1.43.5.1.1.16
I have plain vanilla CouchDB from Apache, which runs as an App running on a Mac OS X 10.9. If I try to attach an attachment to a document that is above 1 Meg in size, it just hangs and does nothing.
I have tried to use couchdbs on Linux, and there the sky is the limit.
I first thought it had to do with low limits on the mac but it doesn't seem so :
➜ ~ ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 709
-n: file descriptors 256
What is causing this ? Why ? And how to fix this ?
Check the config files given by couchdb -c. You probably have this somewhere in them (for some unknown reason):
[couchdb]
max_attachment_size = 1048576 ; bytes
Remove or comment the line and you should be fine.
Or maybe it was compiled with this hardcoded so you could add this line to one of the config file and increase the value.
Update
max_attachment_size is undocumented so probably not safe to use. I leave the original answer as it seems to have solved the problem of the OP but according to the docs, the attachment size should be unlimited. Also attachment_stream_buffer_size is the config key controlling the chunk size of the attachments which might relevant.
I'm attempting to create a fs within a file.
under linux it's very simple:
create a blank file size 8 gb
dd of=fsFile bs=1 count=0 seek=8G
"format" the drive:
mkfs.ext2 fsFile
works great.
however under cygwin running from /usr/sbin ./mkfs.ext2
has all kinds of weird errors (i assume because of some abstraction)
But with cygwin i get:
mkfs.ext2: Device size reported to be zero. Invalid partition specified, or
partition table wasn't reread after running fdisk, due to
a modified partition being busy and in use. You may need to reboot
to re-read your partition table.
or even worse (if i try to access a file through /cygdrive/...
mkfs.ext2: Bad file descriptor while trying to determine filesystem size
:(
please help,
Thanks
Well it seems that the way to solve it is to not use any path on the file you wish to modify.
doing that seems to have solved it.
also it seems that my 8 gig file does have a file size that's simply to big, it seems like it resets the size var i.e.
$ /usr/sbin/fsck.ext2 -f testFile8GiG
e2fsck 1.41.12 (17-May-2010)
The filesystem size (according to the superblock) is 2097152 blocks
The physical size of the device is 0 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
testFile8GiG: 122/524288 files (61.5% non-contiguous), 253313/2097152 blocks
Thanks anyway