Build 8029 - ti_shell.log is being flooded
Since installing build 8029 ti_shell.log is being flooded with "<event id="nnnnn" level="3" module="0" code="0" time="nnnnnnnnnn" message="acronis_drive is not runinng" />"
200-300 of these are being written every second right now. I don't know if that rate is maintained constantly, but I'm up to event id="29092". The log is currently 3115KB large. That's with build 8029 being installed for only 2 days.
I've just reported this to Acronis support but I thought I'd mention it here in case somebody knows something about it. Does this sound familiar? Is there something obvious I've got configured wrong?
https://forum.acronis.com/forum/128200#comment-404559
Not a solution, but a work-a-round (for some log files types - those that are older than a certain period of time... if they keep appending, it won't help) . It also doesn't address why the logs fill up or additional resources. But for cleaning up the log files to free up space...
You can script this in a batch file and have it run as a scheduled task in Windows, as a pre or post cleanup with your backup or manually run it when you want.
Forfiles is built into Windows. This one liner will groom out all files in C:\ProgramData\Acronis\TndLogs that are older than 30 days. With NG having multiple log file directories, you can add multiple paths, or us /S to search subdirectories - just be careful if using *.* as that will look for all files and if you're not careful with the selected directory, you could delete other files. You can also change *.* to *.log to hone in specifically on just files with a .log extension.
forfiles -p "C:\ProgramData\Acronis\TndLogs" -s -m *.* /D -30 /C "cmd /c del @path"
Infor about forfiles switches... https://technet.microsoft.com/en-us/library/cc753551(v=ws.11).aspx
Syntax
forfiles [/p <Path>] [/m <SearchMask>] [/s] [/c "<Command>"] [/d [{+|-}][{<Date>|<Days>}]]
I looked at a system with ATIH 2017 build 8029 and on that the log is 386KB but adding entries slowly - of more concern the monitor.log on that system was around 2.3GB until I deleted it!
So far my monitor.log is pretty small, but records are being added complaining about various failures relating to Sync Agent errors and cloud errors. Since I don't use the Sync Agent of Acronis Cloud services, this is eventually going to make the monitor log pretty big. I hope there is some way to disable whatever is going on here. ATI is obviously wasting cycles on functions I'm not interested in using. I see that that was going on in the log (pre 8029) monitor.log too - 1226KB for about 4 months of log. I think I don't need to worry about it too much.
My ti_shell.log, however, is over 4MB in just 3 days (with the PC asleep for more than a third of the time). Nothing like your 2.3GB, but growing steadily.
Please keep us updated on your Support Case and reference this forum topic (if not already done so).
If/when I hear from Acronis support I'll mention this thread. I'm using email rather than chat (since I didn't want to be tied to my PC) but haven't heard back from them yet.
https://forum.acronis.com/forum/128200#comment-404559
Not a solution, but a work-a-round (for some log files types - those that are older than a certain period of time... if they keep appending, it won't help) . It also doesn't address why the logs fill up or additional resources. But for cleaning up the log files to free up space...
...
forfiles -p "C:\ProgramData\Acronis\TndLogs" -s -m *.* /D -30 /C "cmd /c del @path"
...
The command was just an example? My TndLogs files are all very small - 2KB - and I've got less than 20 of them. My active and large logs are in "C:\ProgramData\Acronis\TrueImageHome\Logs"
I heard from Acronis support. They have opened case #02924417 for this problem.
They suggested I stop and disable the Acronis Sync Agent service, but that did not fix the problem so I FTPed them my system report. I'll report when I hear back from them.
forfiles -p "C:\ProgramData\Acronis\TndLogs" -s -m *.* /D -30 /C "cmd /c del @path"
is good for any system - it will delete logs older than 30 days (-30). You can change -30 to something else. It's only for keeping logs in check as to the number of them, over time. It doesn't help with just large log files or performance due to constant log file writes. Hope to hear back on your issue.
forfiles -p "C:\ProgramData\Acronis\TndLogs" -s -m *.* /D -30 /C "cmd /c del @path"
is good for any system - it will delete logs older than 30 days (-30). You can change -30 to something else. It's only for keeping logs in check as to the number of them, over time. It doesn't help with just large log files or performance due to constant log file writes. Hope to hear back on your issue.
I didn't do a very good job of commenting. I was trying to say that I should probably use
forfiles -p "C:\ProgramData\Acronis\TrueImageHome\Logs" -s -m *.* /D -30 /C "cmd /c del @path"
TndLogs contains nothing worth removing. But I realize that this won't address my problem with ti_shell.log since it gets an updated timestamp every minute, and ATI always has it open. I guess I could occassionally kill ATI (or boot in safe mode) and delete everything from ti_shell.log. That's not worth doing now since I've got 125GB free on my C drive and ti_shell.log is only a bit under 5.5MB right now. But 5.5MB of repeated (and useless) data in just 4 days is a bit worrisome.
Patrick, I would recommend waiting on Acronis to respond to your open support case for the ti_shell.log issue - mine is also over 7MB and that is on build 6116 for New Generation, so it does seem to be something introduced with the changes to these new versions.
Patrick, this issue with the ti_shell.log entries for "acronis_drive is not runinng" looks to be related to a new unwanted behaviour for Acronis Mobile Backup as being reported by other users.
See posts: 128633: Mounting ".tibx" Files (read from post #6) and 128847: After recent update, new drive for Mobile Backup data has overridden and hidden a mapped network drive
<rant>
I just spent some time on the phone with someone from Acronis support. I think he had not done his homework. He used remote access to my PC but did nothing with it other than check the ATI build number and look at the Acronis logs directory. He suggested that the ti_shell.log did not seem too large, and didn't even open it and look at the contents until I suggested it. I couldn't get him interested in the contents of the ti_monitor.0.log at all. He's going to get back to me.
I'm not at all bothered by there not being a solution yet, but I am bothered by the lack of preparation. The support person learned nothing - did not try to learn anything - that wasn't in my initial problem report. Oh, I take that back. If he bothers, he might notice that the log is several MB larger than it was when I reported the problem.
</rant>
Patrick, to keep you updated, I had a reply from Gaidar, General Manager Acronis True Image, earlier today to tell me that he has referred this and the related Acronis drive issues I mentioned in my post above to his development team to investigate. I pointed him at this and the other two posts from the Mobile Backup forum. I created a topic for this in the private MVP forum that I directed Gaidar to look at.
I got a response from Acronis support:
I have checked with the expert team for the ti_shell.log and ti_monitor.0.log, they informed that the logs that is created is normal for the new build of Acronis True Image 2017 - 8029. In case if the ti_shell.log and ti_monitor.0.log, size is increasing you can manually delete the logs.
In other words, "It's supposed to do that". I'm not particularly pleased with that response.
The ti_monitor.0.log is always open when ATI is running (although I don't know what part of Acronis has it open). There is no way to delete it without stopping ATI or booting in Safe Mode. I suspect the ti_shell.log can be deleted whenever it is not being updated. But those "solutions" don't address ATI wasting resources checking for functions I have no interest in.
I know that complaining on this forum serves no purpose except to irritate readers, but I am beginning to lose faith in Acronis.
Patrick, I agree with your reaction to the comments you have received and do not find these acceptible either even though the log file is not growing to a massive file size (yet...!!).
I would recommend sending a PM to Gaidar on this issue to make your feelings known.
I looked at my log and it was up to 14MB and continuously growing. As for the ATI services, I am not running Mobile Backup Server, Mobile Backup Status Server or Nonstop Backup Service. Those are all set to Manual and none are running.
So I simply changed the ti_shell.log file to Read Only and it continued to grow... until I rebooted Windows. Now it has stopped growing. I checked the event log and I'm not seeing anything amiss out of ATI.
Probably not the best solution long term. I'll look forward to a proper fix.
A follow-up on my prior post about setting the file read-only...
I notice that when I do a search in the Explorer, it takes a very long time. So I removed the read-only status on the file and now the Explorer search is fast again. So I guess Acronis was trying and trying to get access and causing some serious load somewhere.
EDIT: I'm not sure the issues are related. So I'm back to leaving the log file as read only until Acronis fixes this. I submitted a report to them as well.
Just wondering if anyone had made any progress in understanding this issue.
I've been running for a while with the ti_shell.log file read-only so it's basically disabled that log. I re-enabled it today and oddly found that what I would get is these six entries about every three to five minutes.
<event id="49" level="2" module="0" code="0" time="1489622967" message="IconOverlayAcronisDrive ctor" />
<event id="50" level="2" module="0" code="0" time="1489622967" message="IconOverlayAcronisDrive ctor" />
<event id="51" level="3" module="0" code="0" time="1489622967" message="acronis_drive is not runinng" />
<event id="52" level="3" module="0" code="0" time="1489622967" message="acronis_drive is not runinng" />
<event id="53" level="3" module="0" code="0" time="1489622967" message="acronis_drive is not runinng" />
<event id="54" level="3" module="0" code="0" time="1489622967" message="acronis_drive is not runinng" />
But I also realized that my backup NAS was on. I usually keep it off save for the two hours a day when I have my backups scheduled. When I turned off the NAS, I found the log file being flooded at a rate of about 200 entries per minute, although it was not a time when anything should have been using the NAS. Some time later, it went back to minimal entries, but didn't stay that way. I'm very confused.
I had opened up a support case but the responses have not been encouraging; I don't feel as though there is a serious communication there. It might help to get an answer to a simple question: What triggers this message?
No idea - I've sent a PM to Support Analyst - Slava
Hello All,
Logs being spammed with "acronis_drive is not runinng" is a known isssue. It is going to be fixed in the next update.
Until then you can workaround the problem at cost of "Acronis Drive" appearing in Windows File Explorer: click on the second tab in Acronis True Image 2017, called "Archive" (right below the "Backup" section that you use most of the time), and create an archive from any file(s). That will turn on acronis_drive.exe process and "acronis_drive is not runinng" flood will stop. Choose a file that you do not need for archiving or create a new "dummy" file for that, because unlike "Backup" function, "Archive" deletes the original file after creating the archive.
Those that use mobile application and store backups from their mobile devices on the PC are not affected by this issue: Acronis Drive is turned on automatically for browsing these backups.
The fix, expected in the next update, consists in greatly reducing the number of triggers for the message "acronis_drive is not runinng" in logs.
Regards,
Slava
Thanks for the update on this issue Slava. To ask an obvious question that will arise, is there any anticipated date for when the next update may be released? Are we looking at weeks, months... etc?
Thanks, Slava. I just tried it. I archived a file, removed the read-only from the log file and rebooted. I only got 110 log entries in the two seconds before acronis_drive started. I'll look forward to the update.
Thank you, Slava! That is a very easy and effective circumvention. That stops the ti_shell.log flood.
The ti_monitor.0.log is still getting its flow (but not flood) of sync agent errors so I guess those are two unrelated problems.
To ask an obvious question that will arise, is there any anticipated date for when the next update may be released? Are we looking at weeks, months... etc?
Steve, current estimates are two-three weeks. Maybe it wil take more time depending on the testing results.
Regards,
Slava
Thanks, Slava
Thank you Slava,
My ti_shell.log was already several 100MB large.
And PDF Xchange Editor took 10 seconds to start. After renaming the log, the PDF Reader starts again immediately.
Greetings
I was wrong about the circumvention stopping the growth. It is certainly lessened, and its behavior is completely changed, but it is still happening. I'm now occassionally getting a few copies of a new message: "IconOverlayAcronisDrive ctor" followed by hundreds of the old "acronis_drive is not runinng" message. I think this happens when my PC wakes from sleep, but not always. It happened at yesterday 12:41:08. There were 198 of the old message, a 2 second break, 130 of the old message, a 4 second break, 127 more messages, a couple more of each of the messages and then nothing until 09:11:54 today. I had my PC up and running most of yesterday afternoon and evening. Today there have been 2 pairs of the IconOverlay message - 2 times that the PC worke from sleep - and nothing else.
I greatly appreciate that the log is not growing at a rapid rate, but something unusual is still going on.
And by the way, the Archive process has 13 open TCP/IP connections to to/from the localhost/loopback addresses. That is, connections between 13 pairs of ports on IP addr 127.0.0.1. Seems a bit odd. Maybe there's a good reason for that, but I'll be happy when the circumvention is not needed.
Patrick, my experience with Slava's recommended circumvention was that there would be a short time (could be under 2 seconds) where the log would get flooded with the messages before the acronis_drive task would get running. I also was getting a couple of the IconOverlay... messages, I think on every boot.
I didn't want to be reminded of this so my circumvention approach was to make the ti_shell.log file read only. Do that, reboot, and then nothing will be written to it. It does not seem to have affected anything else... at least I don't think so.