Problem
Ubuntu 18.04. The logs for some files not sending. For example I have has 16 log files on 2020-06-23. But only #5 & #8 got collected into data.json. Others are not found in data.json
Here's a script I use to found files on disk but not in data.json.
sudo python -c '
import json; import os;
raw = os.listdir("/path/to/my/logdir")
f = open("/var/lib/filebeat/registry/filebeat/data.json", "r")
data=json.load(f)
harvested=[d["source"].split("/")[-1] for d in data]
substraction=[x for x in raw if not x in harvested]
print("\n".join(substraction))
'
The script result, there's just a lot:
app-2020-06-21.20.log
app-2020-06-21.25.log
app-2020-06-23.11.log
app-2020-06-22.1.log
app-2020-06-22.48.log
app-2020-06-21.41.log
app-2020-06-23.15.log
...
And there are only 2 types of logs End of file reached and Non-zero metrics in the last 30s :
Jun 23 12:23:12 filebeat[32738]: 2020-06-23T12:23:12.223Z DEBUG [harvester] log/log.go:107 End of file reached: /path/to/my/logdir/app-2020-06-21.43.log; Backoff now.
Jun 23 12:23:12 filebeat[32738]: 2020-06-23T12:23:12.344Z DEBUG [harvester] log/log.go:107 End of file reached: /path/to/my/logdir/app-2020-06-22.9.log; Backoff now.
Jun 23 12:23:12 filebeat[32738]: 2020-06-23T12:23:12.364Z DEBUG [harvester] log/log.go:107 End of file reached: /path/to/my/logdir/app-2020-06-21.34.log; Backoff now.
Jun 23 12:23:12 filebeat[32738]: 2020-06-23T12:23:12.444Z DEBUG [harvester] log/log.go:107 End of file reached: /path/to/my/logdir/app-2020-06-23.5.log; Backoff now.
Jun 23 12:23:15 filebeat[32738]: 2020-06-23T12:23:15.144Z INFO [monitoring] log/log.go:145 Non-zero metrics in the last 30s {"monitoring": {"metrics": {"beat":{"cpu":{"system":{"ticks":350,"time":{"ms":10}},"total":{"ticks":1710,"ti
Jun 23 12:23:45 filebeat[32738]: 2020-06-23T12:23:45.144Z INFO [monitoring] log/log.go:145 Non-zero metrics in the last 30s {"monitoring": {"metrics": {"beat":{"cpu":{"system":{"ticks":350,"time":{"ms":9}},"total":{"ticks":1720,"tim
Jun 23 12:24:15 filebeat[32738]: 2020-06-23T12:24:15.144Z INFO [monitoring] log/log.go:145 Non-zero metrics in the last 30s {"monitoring": {"metrics": {"beat":{"cpu":{"system":{"ticks":360,"time":{"ms":6}},"total":{"ticks":1740,"tim
Jun 23 12:24:45 filebeat[32738]: 2020-06-23T12:24:45.144Z
Details
Filebeat config
output:
logstash:
enabled: true
hosts:
- x.x.x.x:5044
filebeat:
inputs:
-
paths:
- "/path/to/log/dir/*"
document_type: myapp
multiline.pattern: '^[0-9]{2}:[0-9]{2}:[0-9]{2}.[0-9]{3}'
multiline.negate: true
multiline.match: after
clean_removed: true
close_removed: true
logging.level: debug
name: "myapp"
tags: ["tag1", "tag2"]
Disk
Here's is the usage. I guess disk is fine
Filesystem Size Used Avail Use% Mounted on
... 2.0G 0 2.0G 0% /dev
... 395M 820K 394M 1% /run
... 30G 12G 18G 41% /
Here's the inode checking result. You can see that there's no duplicated inode in 06-23 logs.
ls -il * | grep 06-23
768289 -rw-r--r-- 1 root root 10485996 Jun 23 00:33 app-2020-06-23.0.log
768372 -rw-r--r-- 1 root root 10486447 Jun 23 01:02 app-2020-06-23.1.log
768292 -rw-r--r-- 1 root root 10485819 Jun 23 05:36 app-2020-06-23.10.log
800654 -rw-r--r-- 1 root root 10499153 Jun 23 05:59 app-2020-06-23.11.log
794052 -rw-r--r-- 1 root root 10486575 Jun 23 06:32 app-2020-06-23.12.log
768487 -rw-r--r-- 1 root root 10492683 Jun 23 06:59 app-2020-06-23.13.log
800633 -rw-r--r-- 1 root root 10490445 Jun 23 07:27 app-2020-06-23.14.log
794067 -rw-r--r-- 1 root root 10500849 Jun 23 07:55 app-2020-06-23.15.log
788191 -rw-r--r-- 1 root root 10489159 Jun 23 08:28 app-2020-06-23.16.log
788410 -rw-r--r-- 1 root root 10486744 Jun 23 09:30 app-2020-06-23.17.log
800624 -rw-r--r-- 1 root root 10486794 Jun 23 10:00 app-2020-06-23.18.log
794048 -rw-r--r-- 1 root root 10490002 Jun 23 10:39 app-2020-06-23.19.log
768461 -rw-r--r-- 1 root root 10486161 Jun 23 01:36 app-2020-06-23.2.log
794051 -rw-r--r-- 1 root root 10488204 Jun 23 11:12 app-2020-06-23.20.log
794081 -rw-r--r-- 1 root root 10487146 Jun 23 11:46 app-2020-06-23.21.log
794071 -rw-r--r-- 1 root root 10492866 Jun 23 12:16 app-2020-06-23.22.log
787673 -rw-r--r-- 1 root root 10490849 Jun 23 12:51 app-2020-06-23.23.log
787698 -rw-r--r-- 1 root root 3491076 Jun 23 13:00 app-2020-06-23.24.log
768478 -rw-r--r-- 1 root root 10486306 Jun 23 02:08 app-2020-06-23.3.log
768507 -rw-r--r-- 1 root root 10486690 Jun 23 02:34 app-2020-06-23.4.log
800620 -rw-r--r-- 1 root root 10496353 Jun 23 03:00 app-2020-06-23.5.log
800623 -rw-r--r-- 1 root root 10503668 Jun 23 03:36 app-2020-06-23.6.log
768521 -rw-r--r-- 1 root root 10520722 Jun 23 04:05 app-2020-06-23.7.log
774652 -rw-r--r-- 1 root root 10487379 Jun 23 04:38 app-2020-06-23.8.log
784704 -rw-r--r-- 1 root root 10553972 Jun 23 05:05 app-2020-06-23.9.log
Related
I have a qcow2 image which I have converted to raw format, and then mount to my file system:
# qemu-img convert -O raw initial-image.qcow2 raw-image.img
# kpartx -av raw-image.img
add map loop0p1 (253:1): 0 41940992 linear /dev/loop0 2048
# mount /dev/mapper/loop0p1 ~/myImage
# ls ~/myImage
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
The size of ~/myImage mountpoint is checked with du command as follows:
# du -hx --max-depth=1 ~/myImage/
0 /root/myImage/dev
0 /root/myImage/proc
0 /root/myImage/run
0 /root/myImage/sys
36M /root/myImage/etc
40K /root/myImage/root
53M /root/myImage/var
12K /root/myImage/tmp
834M /root/myImage/usr
89M /root/myImage/boot
0 /root/myImage/home
0 /root/myImage/media
0 /root/myImage/mnt
0 /root/myImage/opt
0 /root/myImage/srv
1012M /root/myImage/
At this point I copied the contents of ~/myImage and pasted them inside ~/myImage-copy directory. Then I checked the size of the newly created directory. I expected the exact same size for each directory between ~/myImage and ~/myImage-copy, but it's not:
# cp -R myImage/ ~/myImage-copy
# du -hx --max-depth=1 ~/myImage-copy/
0 /root/myImage-copy/dev
0 /root/myImage-copy/proc
0 /root/myImage-copy/run
0 /root/myImage-copy/sys
36M /root/myImage-copy/etc
40K /root/myImage-copy/root
63M /root/myImage-copy/var
12K /root/myImage-copy/tmp
862M /root/myImage-copy/usr
89M /root/myImage-copy/boot
0 /root/myImage-copy/home
0 /root/myImage-copy/media
0 /root/myImage-copy/mnt
0 /root/myImage-copy/opt
0 /root/myImage-copy/srv
1.1G /root/myImage-copy/
From the paths above with different size, I chose /usr and I followed a branch of it until I conclude to an innermost directory which has different size, in order to inspect its files. Below is shown the size difference of an innermost directory:
# du -hx --max-depth=1 ~/myImage/usr/lib64/python2.7/json/
112K /root/myImage/usr/lib64/python2.7/json/
# du -hx --max-depth=1 ~/myImage-copy/usr/lib64/python2.7/json/
164K /root/myImage-copy/usr/lib64/python2.7/json/
However, by inspecting their file content, I can't see any difference related to their size. I don't know if the second column plays a role:
# ls -lah ~/myImage/usr/lib64/python2.7/json/
total 200K
drwxr-xr-x. 2 root root 280 Feb 3 11:17 .
drwxr-xr-x. 26 root root 20K Feb 3 11:17 ..
-rw-r--r--. 1 root root 14K Aug 13 2020 decoder.py
-rw-r--r--. 2 root root 12K Aug 13 2020 decoder.pyc
-rw-r--r--. 2 root root 12K Aug 13 2020 decoder.pyo
-rw-r--r--. 1 root root 17K Aug 13 2020 encoder.py
-rw-r--r--. 2 root root 14K Aug 13 2020 encoder.pyc
-rw-r--r--. 2 root root 14K Aug 13 2020 encoder.pyo
-rw-r--r--. 1 root root 15K Aug 13 2020 __init__.py
-rw-r--r--. 2 root root 14K Aug 13 2020 __init__.pyc
-rw-r--r--. 2 root root 14K Aug 13 2020 __init__.pyo
-rw-r--r--. 1 root root 2.3K Aug 13 2020 scanner.py
-rw-r--r--. 2 root root 2.2K Aug 13 2020 scanner.pyc
-rw-r--r--. 2 root root 2.2K Aug 13 2020 scanner.pyo
-rw-r--r--. 1 root root 997 Aug 13 2020 tool.py
-rw-r--r--. 2 root root 1.3K Aug 13 2020 tool.pyc
-rw-r--r--. 2 root root 1.3K Aug 13 2020 tool.pyo
# ls -lah ~/myImage-copy/usr/lib64/python2.7/json/
total 200K
drwxr-xr-x 2 root root 280 Mar 4 17:55 .
drwxr-xr-x 26 root root 20K Mar 4 17:55 ..
-rw-r--r-- 1 root root 14K Mar 4 17:55 decoder.py
-rw-r--r-- 1 root root 12K Mar 4 17:55 decoder.pyc
-rw-r--r-- 1 root root 12K Mar 4 17:55 decoder.pyo
-rw-r--r-- 1 root root 17K Mar 4 17:55 encoder.py
-rw-r--r-- 1 root root 14K Mar 4 17:55 encoder.pyc
-rw-r--r-- 1 root root 14K Mar 4 17:55 encoder.pyo
-rw-r--r-- 1 root root 15K Mar 4 17:55 __init__.py
-rw-r--r-- 1 root root 14K Mar 4 17:55 __init__.pyc
-rw-r--r-- 1 root root 14K Mar 4 17:55 __init__.pyo
-rw-r--r-- 1 root root 2.3K Mar 4 17:55 scanner.py
-rw-r--r-- 1 root root 2.2K Mar 4 17:55 scanner.pyc
-rw-r--r-- 1 root root 2.2K Mar 4 17:55 scanner.pyo
-rw-r--r-- 1 root root 997 Mar 4 17:55 tool.py
-rw-r--r-- 1 root root 1.3K Mar 4 17:55 tool.pyc
-rw-r--r-- 1 root root 1.3K Mar 4 17:55 tool.pyo
In addition, I checked the md5 hash of the files above as a view of their content. It seems there is no content differences between the same files:
# md5sum ~/myImage/usr/lib64/python2.7/json/*
598c681c82c582ca3f17950b4d5413c1 /root/myImage/usr/lib64/python2.7/json/decoder.py
939055a9fdfbbe6ab4d4babeb3ae63f5 /root/myImage/usr/lib64/python2.7/json/decoder.pyc
939055a9fdfbbe6ab4d4babeb3ae63f5 /root/myImage/usr/lib64/python2.7/json/decoder.pyo
007a9954ca6641b29564a0f0cb55096b /root/myImage/usr/lib64/python2.7/json/encoder.py
366d44efbfce1e5b4a3397b15f202765 /root/myImage/usr/lib64/python2.7/json/encoder.pyc
366d44efbfce1e5b4a3397b15f202765 /root/myImage/usr/lib64/python2.7/json/encoder.pyo
dd5db0c7fb7c531be4e14feebbdb52e8 /root/myImage/usr/lib64/python2.7/json/__init__.py
791c8dca2a86ce50ead04e918a17b508 /root/myImage/usr/lib64/python2.7/json/__init__.pyc
791c8dca2a86ce50ead04e918a17b508 /root/myImage/usr/lib64/python2.7/json/__init__.pyo
8d6660f10863f99ffdd9a95eeddd7b64 /root/myImage/usr/lib64/python2.7/json/scanner.py
59865f486b742aea959693c04cfce057 /root/myImage/usr/lib64/python2.7/json/scanner.pyc
59865f486b742aea959693c04cfce057 /root/myImage/usr/lib64/python2.7/json/scanner.pyo
ad879e2ba247d3d4a5cc71fe22db91d0 /root/myImage/usr/lib64/python2.7/json/tool.py
af6b5531a8bc6977bca14e8d34ba8f68 /root/myImage/usr/lib64/python2.7/json/tool.pyc
af6b5531a8bc6977bca14e8d34ba8f68 /root/myImage/usr/lib64/python2.7/json/tool.pyo
# md5sum ~/myImage-copy/usr/lib64/python2.7/json/*
598c681c82c582ca3f17950b4d5413c1 /root/myImage-copy/usr/lib64/python2.7/json/decoder.py
939055a9fdfbbe6ab4d4babeb3ae63f5 /root/myImage-copy/usr/lib64/python2.7/json/decoder.pyc
939055a9fdfbbe6ab4d4babeb3ae63f5 /root/myImage-copy/usr/lib64/python2.7/json/decoder.pyo
007a9954ca6641b29564a0f0cb55096b /root/myImage-copy/usr/lib64/python2.7/json/encoder.py
366d44efbfce1e5b4a3397b15f202765 /root/myImage-copy/usr/lib64/python2.7/json/encoder.pyc
366d44efbfce1e5b4a3397b15f202765 /root/myImage-copy/usr/lib64/python2.7/json/encoder.pyo
dd5db0c7fb7c531be4e14feebbdb52e8 /root/myImage-copy/usr/lib64/python2.7/json/__init__.py
791c8dca2a86ce50ead04e918a17b508 /root/myImage-copy/usr/lib64/python2.7/json/__init__.pyc
791c8dca2a86ce50ead04e918a17b508 /root/myImage-copy/usr/lib64/python2.7/json/__init__.pyo
8d6660f10863f99ffdd9a95eeddd7b64 /root/myImage-copy/usr/lib64/python2.7/json/scanner.py
59865f486b742aea959693c04cfce057 /root/myImage-copy/usr/lib64/python2.7/json/scanner.pyc
59865f486b742aea959693c04cfce057 /root/myImage-copy/usr/lib64/python2.7/json/scanner.pyo
ad879e2ba247d3d4a5cc71fe22db91d0 /root/myImage-copy/usr/lib64/python2.7/json/tool.py
af6b5531a8bc6977bca14e8d34ba8f68 /root/myImage-copy/usr/lib64/python2.7/json/tool.pyc
af6b5531a8bc6977bca14e8d34ba8f68 /root/myImage-copy/usr/lib64/python2.7/json/tool.pyo
So, what is the reason behind the size difference of the same content in du output?
My operating system is CentOS Linux release 7.9.2009.
I am trying to list some selective files but want to exclude atop_20210428, but the following extended glob atop_20210#(3|4)*[0-4]*!(8)* does not exclude the file atop_20210428, what is the correction required in that?.
[root#server atop]# ls -lh atop_20210#(3|4)*[0-4]*!(8)*
-rw-r--r-- 1 root root 81M Mar 31 00:00 atop_20210330
-rw-r--r-- 1 root root 80M Apr 1 00:00 atop_20210331
-rw-r--r-- 1 root root 79M Apr 2 00:00 atop_20210401
-rw-r--r-- 1 root root 82M Apr 3 00:00 atop_20210402
-rw-r--r-- 1 root root 82M Apr 4 00:00 atop_20210403
-rw-r--r-- 1 root root 81M Apr 5 00:00 atop_20210404
-rw-r--r-- 1 root root 80M Apr 6 00:00 atop_20210405
-rw-r--r-- 1 root root 81M Apr 7 00:00 atop_20210406
-rw-r--r-- 1 root root 81M Apr 8 00:00 atop_20210407
-rw-r--r-- 1 root root 81M Apr 9 00:00 atop_20210408
-rw-r--r-- 1 root root 80M Apr 10 00:00 atop_20210409
-rw-r--r-- 1 root root 81M Apr 11 00:00 atop_20210410
-rw-r--r-- 1 root root 80M Apr 12 00:00 atop_20210411
-rw-r--r-- 1 root root 82M Apr 13 00:00 atop_20210412
-rw-r--r-- 1 root root 81M Apr 14 00:00 atop_20210413
-rw-r--r-- 1 root root 81M Apr 15 00:00 atop_20210414
-rw-r--r-- 1 root root 79M Apr 16 00:00 atop_20210415
-rw-r--r-- 1 root root 78M Apr 17 00:00 atop_20210416
-rw-r--r-- 1 root root 80M Apr 18 00:00 atop_20210417
-rw-r--r-- 1 root root 78M Apr 19 00:00 atop_20210418
-rw-r--r-- 1 root root 81M Apr 20 00:00 atop_20210419
-rw-r--r-- 1 root root 79M Apr 21 00:00 atop_20210420
-rw-r--r-- 1 root root 82M Apr 22 00:00 atop_20210421
-rw-r--r-- 1 root root 81M Apr 23 00:00 atop_20210422
-rw-r--r-- 1 root root 82M Apr 24 00:00 atop_20210423
-rw-r--r-- 1 root root 81M Apr 25 00:00 atop_20210424
-rw-r--r-- 1 root root 83M Apr 26 00:00 atop_20210425
-rw-r--r-- 1 root root 83M Apr 27 00:00 atop_20210426
-rw-r--r-- 1 root root 83M Apr 28 00:00 atop_20210427
-rw-r--r-- 1 root root 29M Apr 28 08:35 atop_20210428
I did turn on extglob already:
[root#server atop]# shopt -p extglob
shopt -s extglob
[root#server atop]#
[root#server atop]# shopt | grep extglob
extglob on
* is matching everything, so *!(8)* is always going to match everything - first !(8) will not match anything (match empty), then * will match everything.
atop_20210 #(3|4) * [0-4] * !(8) *
atop_20210 4 2 8
Why all the *? Remove them. You want to just match what you want to match, not to match anything in between. Just:
atop_20210#(3|4)[0-4]!(8)
I am debugging a pwmtachtool<->hwmon interaction problem, observed when OpenBMC image is running
on an AST2600 EVB, which is connected to a SensorsBoard and a Fan (Host is not connected).
The running OpenBMC image was built using bitbake, and it includes recipes-phosphor/configuration/entity-manager/SensorBoard.json,
customized for this SensorBoard. Verified that I2C sensors on the SensorsBoard are accessible via i2ctools,
and behave as expected. However, running "pwmtachtool <dev_id> --get-fan-speed <fan_num>" consistently
reports "Fan speed is 0", even though phy Fan is properly connected.
For example:
/usr/local/bin/pwmtachtool 0 --get-fan-speed 0 --verbose
GET_TACH_SPEED:rpm value 0
Fan 0 speed is 0
cat /sys/class/hwmon/hwmon0/fan0_input
0
Looking closely at the pwmtachtool codepath, I am seeing that it calls pwmtach_action(), which reads
"/sys/class/hwmon/hwmon<dev_id>/fan", which is always 0. Tried all <dev_id>/ combinations,
exposed by sysfs: same result. So far, unable to figure out why this is so.
I would really appreciate all recommendations for how to debug this problem.
Additional details:
ll /sys/class/hwmon/
lrwxrwxrwx 1 root root 0 Feb 16 08:52 hwmon0 -> ../../devices/platform/ahb/ahb:apb/1e610000.pwm-tacho-controller/hwmon/hwmon0
lrwxrwxrwx 1 root root 0 Feb 16 08:52 hwmon1 -> ../../devices/platform/iio-hwmon/hwmon/hwmon1
lrwxrwxrwx 1 root root 0 Feb 26 22:20 hwmon2 -> ../../devices/platform/ahb/ahb:apb/ahb:apb:bus#1e78a000/1e78a480.i2c-bus/i2c-8/8-004d/hwmon/hwmon2
ll /sys/class/hwmon/hwmon0/*
lrwxrwxrwx 1 root root 0 Feb 26 22:20 /sys/class/hwmon/hwmon0/device -> ../../../1e610000.pwm-tacho-controller
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan0_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan10_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan11_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan12_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan13_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan14_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan15_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan1_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan2_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan3_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan4_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan5_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan6_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan7_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan8_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/fan9_input
-r--r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/name
lrwxrwxrwx 1 root root 0 Feb 26 22:20 /sys/class/hwmon/hwmon0/of_node -> ../../../../../../../firmware/devicetree/base/ahb/apb/pwm-tacho-controller#1e610000
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm0
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm1
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm10
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm11
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm12
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm13
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm14
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm15
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm2
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm3
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm4
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm5
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm6
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm7
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm8
-rw-r--r-- 1 root root 4096 Feb 26 22:20 /sys/class/hwmon/hwmon0/pwm9
lrwxrwxrwx 1 root root 0 Feb 16 08:52 /sys/class/hwmon/hwmon0/subsystem -> ../../../../../../../class/hwmon
-rw-r--r-- 1 root root 4096 Feb 16 08:52 /sys/class/hwmon/hwmon0/uevent
In my case, the problem was because of J80 jumper connected PWM and TACH lines. So, when I removed it pwmtachtool started to work as expected.
[root#amp logs]# ls -l
total 0
-rw-r--r-- 1 root root 0 Nov 23 17:51 lb-quarzcenter.log
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-01
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-02
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-03
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-04
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-05
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-06
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-07
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-08
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-10
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-11
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-12
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-13
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-14
-rw-r--r-- 1 root root 0 Nov 23 17:51 lb-quarzcenter.log.2019-02-15
-rw-r--r-- 1 root root 0 Feb 27 17:26 lb-quarzcenter.log.2019-02-09
How do I match a string with year-month-date and delete 10 days ago file according to lb-quarzcenter.log.*?
now=$(date +%s) # express current time as seconds since 1970-01-01
(( ten_days_ago = now - 60*60*24*10 )) # subtract 864000 seconds (10 days) from that
date_minus_ten=$(date +%F --date="#$ten_days_ago") # express that number as a YYYY-MM-DD
for filename in lb-quartzcenter.log.* ; do # loop over all matching files
filedate="${filename/lb-quartzcenter.log./}" # remove the filename part before the timestamp
if [[ $filedate < $date_minus_ten ]] ; then # if filename remainder is lexicographically lower...
rm -f "$filename" # ... remove the file
fi
done
I intent to enumerate the files and dirs
[root#iz2ze9wve43n2nyuvmsfx5z /]# ls -lh |nl
1 total 60K
2 lrwxrwxrwx 1 root root 7 Jun 15 22:08 bin -> usr/bin
3 dr-xr-xr-x. 5 root root 4.0K Jun 15 22:10 boot
4 drwxr-xr-x 19 root root 2.9K Sep 17 11:35 dev
5 drwxr-xr-x. 85 root root 4.0K Sep 18 22:44 etc
6 drwxr-xr-x. 2 root root 4.0K Sep 17 08:25 home
7 lrwxrwxrwx 1 root root 7 Jun 15 22:08 lib -> usr/lib
8 lrwxrwxrwx 1 root root 9 Jun 15 22:08 lib64 -> usr/lib64
9 drwx------. 2 root root 16K Oct 15 2017 lost+found
10 drwxr-xr-x. 2 root root 4.0K Apr 11 2018 media
11 drwxr-xr-x. 2 root root 4.0K Apr 11 2018 mnt
12 drwxr-xr-x. 2 root root 4.0K Apr 11 2018 opt
13 dr-xr-xr-x 86 root root 0 Sep 17 11:35 proc
14 drwxrwxrwx. 21 root root 4.0K Oct 22 08:11 root
15 drwxr-xr-x 24 root root 660 Oct 24 19:10 run
16 lrwxrwxrwx 1 root root 8 Jun 15 22:08 sbin -> usr/sbin
17 drwxr-xr-x. 2 root root 4.0K Apr 11 2018 srv
18 dr-xr-xr-x 13 root root 0 Oct 21 19:50 sys
19 drwxrwxrwt. 11 root root 4.0K Oct 24 05:19 tmp
20 drwxr-xr-x. 13 root root 4.0K Jun 15 22:08 usr
21 drwxr-xr-x. 19 root root 4.0K Jun 15 22:08 var
It starts with 1 which I desire is 0.
How could make nl to enumerate from a specified line.
You just need to use the -v option, and specify to start from 0; your instruction becoming:
ls -lh |nl -v 0
Lets have a look at nl --help:
$ nl --help
Usage: nl [OPTION]... [FILE]...
Write each FILE to standard output, with line numbers added.
With no FILE, or when FILE is -, read standard input.
Mandatory arguments to long options are mandatory for short options too.
...
-v, --starting-line-number=NUMBER first line number for each section
Therefore:
$ nl -v0 <<EOF
> a
> b
> EOF
0 a
1 b
Note that it does not really matter whether you want to enumerate directories or anything else, which is why you probably should strip this part from your question to make it more specific.