I have a strange issue with logrotate on a Raspbian 9 system.
Logrotate appears to be configured to rotate /var/log/syslog every seven days. When I run logrotate -f -d /etc/logrotate.conf the output tells me:
rotating pattern: /var/log/syslog
forced from command line (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/syslog
Now: 2021-03-16 09:56
Last rotated at 2020-11-02 12:26
log needs rotating
rotating log /var/log/syslog, log->rotateCount is 7
dateext suffix '-20210316'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
renaming /var/log/syslog.7.gz to /var/log/syslog.8.gz (rotatecount 7, logstart 1, i 7),
renaming /var/log/syslog.6.gz to /var/log/syslog.7.gz (rotatecount 7, logstart 1, i 6),
renaming /var/log/syslog.5.gz to /var/log/syslog.6.gz (rotatecount 7, logstart 1, i 5),
renaming /var/log/syslog.4.gz to /var/log/syslog.5.gz (rotatecount 7, logstart 1, i 4),
renaming /var/log/syslog.3.gz to /var/log/syslog.4.gz (rotatecount 7, logstart 1, i 3),
renaming /var/log/syslog.2.gz to /var/log/syslog.3.gz (rotatecount 7, logstart 1, i 2),
renaming /var/log/syslog.1.gz to /var/log/syslog.2.gz (rotatecount 7, logstart 1, i 1),
renaming /var/log/syslog.0.gz to /var/log/syslog.1.gz (rotatecount 7, logstart 1, i 0),
log /var/log/syslog.8.gz doesn't exist -- won't try to dispose of it
renaming /var/log/syslog to /var/log/syslog.1
creating new /var/log/syslog mode = 0640 uid = 0 gid = 4
running postrotate script
running script with arg /var/log/syslog: "
invoke-rc.d rsyslog rotate > /dev/null
"
So it says it is renaming /var/log/syslog to /var/log/syslog.1 and creating a new syslog. So everything appears to be ok so far.
Just, it does noting. There is no syslog.1 afterwards and the syslog file is the same as before. Nothing happened.
One thing to mention: /var/log is tmpfs- is this related?
Mounted as: tmpfs on /var/log type tmpfs (rw,nosuid,nodev,relatime)
Thanks for ideas!
/KNEBB
And to update the issue here: I was so dumb not reading. When running in debug mode (as done above) logrotate does nothing- it just tells you what it would be if run without "-d".
Related
I am trying to migrate my cuda application using the dpct. When calling dpct; I see it processes CUDA files and generates some benign warnings but at the end it exits without writing out any DPC++ equivalent file.I can clearly see CUDA functions called in these applications and removal of CUDA path would fail the compile process.This is the command I used
$ dpct --report-type=all --cuda-include-path=/usr/local/cuda-10.2/include -p compile_commands.json"
I have eliminated the actual physical paths to files to avoid confusion:
Processing: ....../ComputeThermoGPU.cu
Processing: ....../CommunicatorGPU.cu
Processing: ....../ParticleData.cu
Processing: ....../Integrator.cu
------------------APIS report--------------------
API name Frequency
-------------------------------------------------
----------Stats report---------------
File name, LOC migrated to DPC++, LOC migrated to helper functions, LOC not needed to migrate,
LOC not able to migrate
....../Integrator.cu, 1, 0, 168, 0
....../ParticleData.cu, 1, 0, 402, 0
....../ComputeThermoGPU.cu, 1, 0, 686, 0
....../ParticleGroup.cu, 6, 0, 111, 0
Total migration time: 17207.371000 ms
-------------------------------------
dpct exited with code: 1 (Migration not necessary)```
I could get a solution to my own question
Use
dpct -p compile_commands.json --in-root=src --out-root=dpct_out --process-all
I think the reason might be, due to the absence of the driver code(containing main function), DPCT thinks that since these helper .cu files are not being utilized anyway, there is no need to perform migration on these files. That's the reason you see "Migration not necessary" warning.
I hope to don't create any duplicate but I looked around (stack overflow and other forum) and I found some similar question but none of them solved my problem.
I have a python code that the only thing that does is query the DB, create a DataFrame in Pandas and write it to an Excel file.
The code worked without problem locally but when I introduced it in my server it start to give this error:
File "Test.py", line 34, in <module>
test()
File "Test.py", line 31, in test
ex.generate_file()
File "/home/carlo/Test/Utility/ExportExcell.py", line 96, in generate_file
writer.save()
File "/usr/local/lib/python2.7/dist-packages/pandas/io/excel.py", line 1952, in save
return self.book.close()
File "/usr/local/lib/python2.7/dist-packages/xlsxwriter/workbook.py", line 306, in close
self._store_workbook()
File "/usr/local/lib/python2.7/dist-packages/xlsxwriter/workbook.py", line 677, in _store_workbook
xlsx_file.write(os_filename, xml_filename)
File "/usr/lib/python2.7/zipfile.py", line 1135, in write
zinfo = ZipInfo(arcname, date_time)
File "/usr/lib/python2.7/zipfile.py", line 305, in __init__
raise ValueError('ZIP does not support timestamps before 1980')
ValueError: ZIP does not support timestamps before 1980
To ensure that is everything ok I printed my DataFrame and for me it looks good even because when I run it locally it geenrate an excell file without problem:
Computer_System_Memory_Size Count_of_HostName Disk_Total_Size Number_of_CPU OS_Family
0 5736053088256 70 6072238035456 282660 Windows
1 96159653888 607 96630589440 2451066 vCenter
2 0 9 0 36342 Virtualization
3 2469361287143424 37 2389533519619072 149406 Unix
4 3691651514368 90 5817485303808 363420 Linux
I don't see any timestamp here and this is part of my code:
pivot = pd.DataFrame.from_dict(pivot) #pivot= information extracted from DB
pd.to_numeric(pivot['Count_of_HostName'], downcast='signed')#try to enforce to be a numeric value in case it get confused with a datetime
pd.to_numeric(pivot['Disk_Total_Size'], downcast='signed')#try to enforce to be a numeric value in case it get confused with a datetime
pd.to_numeric(pivot['Computer_System_Memory_Size'], downcast='signed')#try to enforce to be a numeric value in case it get confused with a datetime
pd.to_numeric(pivot['Number_of_CPU'], downcast='signed')#try to enforce to be a numeric value in case it get confused with a datetime
print pivot
name = 'TempReport/Report.xlsx'#set-up file name
writer = pd.ExcelWriter(name, engine='xlsxwriter')#create excel with file name
pivot.to_excel(writer, 'Pivot', index=False)#introduce my data to excel
writer.save()#write to file, it's where it fail
Does someone know why it doesn't work in an Ubuntu 16.04 server without give me 'ZIP does not support timestamps before 1980' error?
I checked many things, library version, ensure that there are no data
XlsxWriter set the individual XML files that make up an XLSX file with a creation date of 1/1/1980 which is (I think) the ZIP epoch and the date used by Excel. This allows binary reproducibility of files created by XlsxWriter once the same input data and metadata is used.
It sets the date as follows (for the non-in-memory zipfile.py) case:
timestamp = time.mktime((1980, 1, 1, 0, 0, 0, 0, 0, 0))
os.utime(os_filename, (timestamp, timestamp))
The error that you are seeing occurs when this fails in some way and the date is set before 1/1/1980.
I've only seen this happen once before in a situation where the user was using a container and the container had a different time to the host system.
Do you have a situation like this or where the timestamp may be set incorrectly for some reason?
Update: Try run this in the same environment as the example that fails:
import os
import time
filename = 'file.txt'
file = open(filename, 'w')
file.close()
timestamp = time.mktime((1980, 1, 1, 0, 0, 0, 0, 0, 0))
os.utime(filename, (timestamp, timestamp))
print(time.ctime(os.path.getmtime(filename)))
# Should give:
# Tue Jan 1 00:00:00 1980
Update: This issue is fixed in XlsxWriter >= 1.1.9.
Try using this engine:
pd.to_excel('file_name.xlsx', engine = 'openpyxl')
This issue is fixed in XlsxWriter 1.2.1!
Yesterday, I was happily using Byobu/tmux (byobu version 5.74, tmux 2.0) with zsh as shell on my machine. Starting from this morning on, every byobu session just hangs after a small time interval and does not accept any input anymore. I start the session and then, for a while (around 0-15 seconds), I see the clock updating in the status bar - and suddenly it stops and I cannot do anything apart from killing tmux.
I already deleted ~/.byobu which did not change anything. Also changing my shell back to bash did not result in any further success... Running byobu as root does not exhibit the problem, switching to screen as backend also fixes it.
When running byobu with strace, the last lines of the log before the crash are
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}], 2, 4294967295) = 1 ([{fd=6, revents=POLLIN}])
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
close(5) = 0
close(7) = 0
recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\317\0\0\0\20\0\0\0\10\0\0\0\377\377\377\377", 65535}], msg_controllen=0, msg_flags=0}, 0) = 16
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN|POLLOUT}], 2, 4294967295) = 1 ([{fd=6, revents=POLLOUT}])
sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\320\0\0\0\20\0\0\0\10\0\0\0\377\377\377\377", 16}], msg_controllen=0, msg_flags=0}, 0) = 16
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}], 2, 4294967295) = 1 ([{fd=4, revents=POLLIN}])
recvfrom(4, "a", 1, 0, NULL, NULL) = 1
[ last two lines repeated 20 times ]
I can also attach the complete trace if that helps, or provide other debugging data if told how to :)
I recently bought a M500 Sport DV Cam. I am unable to reset/change Date and Time. According to Manual, Cam will create SportDV.txt file in SDCard and we can change Date Time from SportDV.txt file.
But My Cam is not creating any SportDV.txt file. It only creates Two folders Data (which contains an empty base.dat file) and DCIM (Which contains videos and Images).
I tried to create file Manually, but It doesn't change Date/Time. I also tried different methods like creating files with name times.txt, time.txt, timeset.txt, tag.txt, settime.txt but nothing works.
I am unable to change Date and Time. It always shows Year 2158 instead of 2015.
Sample Date: 2158/8/14 22:10:22
I tried everything and failed. But I found the solution.
Open Notepad and Copy & Paste
SPORTS DV
UPDATE:N
FORMAT
EV:6
CTST:100
SAT:100
AWB:0
SHARPNESS:100
AudioVol:1
QUALITY:0
LIGHTFREQ:0
AE:0
RTCDisplay:1
year:2014
month:7
date:7
hour:16
minute:11
second:0
-------------------------------
Exposure(EV)
0 ~ 12, def:6
Contrast(CTST)
1 ~ 200, def:100
Saturation(SAT)
1 ~ 200, def:100
White Balance(AWB)
0 ~ 3, def:0, 0(auto), 1(Daylight), 2(Cloudy), 3(Fluorescent)
Sharpness
1 ~ 200, def:100
AudioVol
0 ~ 2, def:1, 0:Max 1:Mid 2:Min
QUALITY
0 ~ 2, def:0, 0:High 1:Middle 2:Low
LIGHTFREQ
0 ~ 1, def:0, 0:60Hz 1:50Hz
AUTO EXPOSURE(AE)
0 ~ 2, def:0, 0:Average 1:Center 2:Spot
RTCDisplay
0 ~ 1, def:1, 0:Off 1:On
year
2012 - 2038, def:2013
month
01 - 12, def:1
date
01 - 31, def:1
hour
00 - 23, def:0
minute
01 - 59, def:0
second
01 - 59, def:0
Set Update:N to Update:Y,
Change year, month, date ,
and save the file with the name SportDV and Encoding to UTF-8
For versions that have a time.bat file putting a N at the end of the timestamp in the time.txt file removes the timestamp from the video, ie time.txt:
2015.11.13 20:13:31 N
i have the more recent version of the m500 mini camera that doesnt use the sportdv.txt file
It looks same physically as earlier one, same leds, same decals but it instead after being reset has a time.bat file in the root of the card. executing this on a windows machine produced a file called time.txt except the format of this batch file doesnt work,
i edited the time.txt file and restated the camera and it worked after following andys format from his posting on the dx.com site
choose edit and then make sure you replace the (probably nonsense format) contents with 2015.11.13 20:13:31 - in this case that's YYYY.MM.DD HH:MM:SS click save. turn off/eject the camera. Power up now not connected to PC and make a short capture. Now when you check the content the date/time will hopefully be right?
afaik there is no updated firmware for this version of the camera to change from 3 min files or hide the time/date text :-(
I can't recompile any apk with apktool, here is the error log:
W: Could not find sources
invalid resource directory name: C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\res values-?#-rES
Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [C:\Users\PRADEE~1\AppData\Local\Temp\brut_util_Jar_5055861152156375473.tmp, p, --forced-package-id, 1, --min-sdk-version, 21, --target-sdk-version, 21, --version-code, 21, --version-name, 5.0.2-d3aebb81ea, -F, C:\Users\PRADEE~1\AppData\Local\Temp\APKTOOL1542257552202253955.tmp, -x, -0, arsc, -S, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\res, -M, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\AndroidManifest.xml]
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:437)
at brut.androlib.Androlib.buildResources(Androlib.java:374)
at brut.androlib.Androlib.build(Androlib.java:277)
at brut.androlib.Androlib.build(Androlib.java:250)
at brut.apktool.Main.cmdBuild(Main.java:225)
at brut.apktool.Main.main(Main.java:84)
Caused by: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [C:\Users\PRADEE~1\AppData\Local\Temp\brut_util_Jar_5055861152156375473.tmp, p, --forced-package-id, 1, --min-sdk-version, 21, --target-sdk-version, 21, --version-code, 21, --version-name, 5.0.2-d3aebb81ea, -F, C:\Users\PRADEE~1\AppData\Local\Temp\APKTOOL1542257552202253955.tmp, -x, -0, arsc, -S, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\res, -M, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\AndroidManifest.xml]
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:488)
at brut.androlib.Androlib.buildResourcesFull(Androlib.java:423)
... 5 more
Caused by: brut.common.BrutException: could not exec command: [C:\Users\PRADEE~1\AppData\Local\Temp\brut_util_Jar_5055861152156375473.tmp, p, --forced-package-id, 1, --min-sdk-version, 21, --target-sdk-version, 21, --version-code, 21, --version-name, 5.0.2-d3aebb81ea, -F, C:\Users\PRADEE~1\AppData\Local\Temp\APKTOOL1542257552202253955.tmp, -x, -0, arsc, -S, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\res, -M, C:\Users\pradeepkumar\Downloads\Compressed\Advanced+ApkTool+v4.1.0+By+BDFreak\AdvancedApkTool\3-Out\framework-res.apk\AndroidManifest.xml]
at brut.util.OS.exec(OS.java:89)
at brut.androlib.res.AndrolibResources.aaptPackage(AndrolibResources.java:482)
... 6 more
This has been fixed in the latest apktool code base, RC4 does not have this fix. I blogged about fixing this bug a few days ago. So build from source or wait for the final release of Apktool.
Basically the BCP-47 qualifier and 3 characters packed into 2 bytes is not supported with the version you have. Thus ast-rES is decoded improperly, which creates the invalid directory error.