[Bug 32832] New: Wine logs fill the HD in a few seconds and bring down the machine
http://bugs.winehq.org/show_bug.cgi?id=32832 Bug #: 32832 Summary: Wine logs fill the HD in a few seconds and bring down the machine Product: Wine Version: 1.5.22 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: scallegari(a)arces.unibo.it Classification: Unclassified After the update to wine-1.5.22, on a kubuntu quantal 64 bit machine, with the wine shipped through the wine apt repo, I have a huge issue. Wine floods the screen with 'fixme:wtsapi:WTSWaitSystemEvent Stub (nil) 0x00000078 0x94e964' (which is bad but tolerable). Most important it fills .wine/drive_c/users/callegar/Application Data/APP_NAME_NON_STRING/Logs with HUGE log files. In a few seconds these may reach many GBs, fill the machine HD and bring the machine down. The log files have names such as 2013.01.28_12.26.08_PID000033_HelperService.HTM and 2013.01.28_12.26.09_PID000041_ConversionService.HTM The file giving issues is the helper service one, that gets filled by Win32 error in file M:\TemporaryBuilds\2\80\Sources\soda-release\services\HelperService\SessionWatcher.cpp in line 221 code = 2. Message: File not found. In just *one second* of wine, this file got to 42MB. Would be nice if wine did not enable this log mechanism by default, but only after a command line flag. Also, it would be nice if repeated messages could be squelched. Finally, why not printing also which file is not found in the log? As a workaround. Make .wine/drive_c/users/callegar/Application Data/APP_NAME_NON_STRING/Logs not writable by anybody. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 Rico <kgbricola(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal --- Comment #1 from Rico <kgbricola(a)web.de> 2013-01-28 07:11:01 CST --- Which app are you using? Does it happen with a clean prefix too? Searching google for HelperService and APP_NAME_NON_STRING shows that there might be the same problem on win (for e.g.: PDFCreator or PDF Architect). Not a blocker, please see http://bugs.winehq.org/page.cgi?id=fields.html#importance , at best will it is minor, since an easy workaround is present. Please run a regression test, see http://wiki.winehq.org/RegressionTesting . -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #2 from Sergio Callegari <scallegari(a)arces.unibo.it> 2013-01-28 07:41:37 CST --- Hi, restarted with a clean prefix and this seems to be gone. Apparently something went wrong with the updating of the config after wine was updated. Now, apps cannot find hh.exe anymore, but for the rest the major issue is gone. I dare to think that the priority should be quite high. Filling the disk in this way for a networked machine serving not just the user who is running wine at the console means almost certain data loss for those who are working from remote. And you discover the workaround only after the data loss. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #3 from Rico <kgbricola(a)web.de> 2013-01-28 07:56:44 CST --- You have not stated which app you were using, so we could not help you, I think. But I think it may be PDF Creator or so ... Did you had that installed? You may have a look here http://forums.pdfforge.org/discussion/10469/helperservice-exe-belegt-komplet... , it's in german ... If a user should not be able to fill the disk, you may use a disk quota ... but that's another issue and has nothing to do with wine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #4 from Rico <kgbricola(a)web.de> 2013-01-28 09:06:50 CST --- Don't get me wrong, I still think there might be a problem in wine. You may search the hh.exe (it should be in $prefix/drive_c/windows - if it is the default prefix then ~/.wine/drive_c/windows). If it is not there, there may be a packaging issue. It should be there if you create a new prefix and have a look in there (see http://wiki.winehq.org/FAQ#wineprefix ). Which wine version was the last working one? (before you did the wine update) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #5 from Sergio Callegari <scallegari(a)arces.unibo.it> 2013-01-28 09:13:05 CST --- Hi, the app that I am using is LT-Spice. The bug was probably related to an install of Soda PDF that after uninstall left something around that wine could not manage correctly on update from the previous minor version. For what concerns the help file, I am sure it is a problem of LT-Spice. It tries to detect wine to second it, and probably in some occasions it makes wrong guesses. For some reasons, hh is in place, but scad3 when asked to show its help opens a wine explore window. If from there I find the ltspice chm and I click on it another wine explore window opens. Weird For the disk, I know that quotas can save the day, but in this case the user was myself, so I thought I did not need it. Unfortunately by filling the disk I ruined the work of someone who was working from remote. The fact that scared me was that the filling was so fast that the disk notifier did not even have time to alert me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #6 from Austin English <austinenglish(a)gmail.com> 2013-01-28 13:38:48 CST --- Testing in a clean prefix (without cruft from uninstalled programs) would also be useful. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #7 from Sergio Callegari <scallegari(a)arces.unibo.it> 2013-01-30 04:03:05 CST --- Hi, as mentioned working in a clear prefix solves the issue. This is certainly more related to some misbehaving windows application than to wine. I believe that the bug can possibly be closed. Sorry for the noise. Two more notes: - Would be nice if wine could define quotas for its drives, rather than setting quotas for the whole homes of the users of wine. Or anyway introduce some system to avoid filling the user's home. Note that setting quotas for users, can avoid the machines from coming down if the wine 'drives' start taking too much space, but will not prevent data loss if the disk suddendly fills and the user has some other apps working. Unfortunately, many apps when trying to save to disk do not fail gracefully if the disk is full, but corrupt the whole document. So the risk of data loss is important. - After re-starting with a new prefix, I had to reinstall applications. Many apps that used to go to "Program Files" now go to "Program files (x86)" during install (I do not know if this is a change in the apps or in wine). However the result is that for some apps the help system breaks. I have made a few tests and it looks like it is the "()" in the path that creates issues. I have posted a separated bug for this as 32833. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #8 from Nikolay Sivov <bunglehead(a)gmail.com> 2013-01-30 04:20:09 CST --- (In reply to comment #7)
Two more notes:
- Would be nice if wine could define quotas for its drives, rather than setting quotas for the whole homes of the users of wine. Or anyway introduce some system to avoid filling the user's home. Note that setting quotas for users, can avoid the machines from coming down if the wine 'drives' start taking too much space, but will not prevent data loss if the disk suddendly fills and the user has some other apps working. Unfortunately, many apps when trying to save to disk do not fail gracefully if the disk is full, but corrupt the whole document. So the risk of data loss is important.
That's should be done at system level, wine doesn't know about quotas.
- After re-starting with a new prefix, I had to reinstall applications. Many apps that used to go to "Program Files" now go to "Program files (x86)" during install (I do not know if this is a change in the apps or in wine). However the result is that for some apps the help system breaks. I have made a few tests and it looks like it is the "()" in the path that creates issues. I have posted a separated bug for this as 32833.
That change in path means you're running win64-capable wine now, and 32bit applications are installed in (x86) subdir. That's how it works. To verify if that's really '(' that makes a difference you need to create some dir outside on 'Program Files', on C: root for example and try with it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #9 from Sergio Callegari <scallegari(a)arces.unibo.it> 2013-01-30 04:26:53 CST --- Maybe suggesting that users of wine are in a wine group, making .wine owned by group wine and sgid and applying a group quota on wine could be a viable solution? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #10 from Austin English <austinenglish(a)gmail.com> 2013-01-30 13:24:13 CST --- (In reply to comment #9)
Maybe suggesting that users of wine are in a wine group, making .wine owned by group wine and sgid and applying a group quota on wine could be a viable solution?
That's a system administrator decision. Wine expects the WINEPREFIX to be owned/controlled by the user running it, not for them to be shared between multiple users/groups. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32832 --- Comment #11 from Sergio Callegari <scallegari(a)arces.unibo.it> 2013-01-30 13:39:53 CST --- Well, it was not meant for sharing the directory WINEPREFIX among multiple users. It is the typical workaround for the fact that most filesystems (with a few exceptions) do not support per-directory quotas, so that a quota cannot be attached to the WINEPREFIX. Basically you create a group for each directory you want a quota on and you use group quotas. But I agree it is clumsy and cannot be implemented without the aid of the admin. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32832 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Austin English <austinenglish(a)gmail.com> --- Invalid. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32832 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #13 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org