Bug#946958: sa-compile failing on Graylisting.pm
On Wed, 18 Dec 2019, Noah Meyerhans wrote: [snip] The problem is likely related to the fixes for CVE-2018-11805, which involved malicious rulesets invoking arbitrary commands as the uid running spamassassin/spamd. In the case of sa-exim, the line triggering the taint failure is performing an "eval" operation of configuration data read directly from a .cf file, so changing spamasassin's behavior is probably not ideal. I've tested a backport of sa-exim 4.2.1-16 from stretch to jessie, and have observed that the problem does not occur in this scenario. So an update of sa-exim in jessie might be the least disruptive path to a fix here. In the mean time, you might consider locally building it. Hi Noah, I tried backporting sa-exim 4.2.1-16 to jessie. While it installs and fixes the installation problem with sa-compile, for some reason it broke grey listing on my system. Basically, every email that gets grey listed will continually get temporary rejection until the other server gives up. It appears that no email once it is greylisted will ever get through. I'm not sure if this is specific to my setup due to a quirk of my configuration settings and a minor incompatibility between the stretch and jessie versions of sa-exim or something more serious. Log files did not reveal anything obvious nor did a quick review of the differences between the sources of the two versions. For now I have just disabled greylisting on my server, unfortunately I don't have time right now for a more in-depth analysis as I would have to re-learn how all of this works. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | Biotechnology Development Services Telephone USA: +1 541-929-4089 | USA and the Netherlands Netherlands: +31 85 208 5570 | www.deatech.com
Bug#928121: Same problem on Lenovo T480
I'm having what appears to be the same problem with a few differences of note: - Lenovo T480 (original report was for a T580) - Linux kernel 4.19.0-6-amd64 - lxdm - xfce4 - External monitor connected via HDMI Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | Biotechnology Development Services Telephone USA: +1 541-929-4089 | USA and the Netherlands Netherlands: +31 85 208 5570 | www.deatech.com
Bug#932101: release-notes: S3QL unable to resolve hostname due to S3 URL format change
Package: release-notes Severity: normal Dear Maintainer, After upgrading from Stretch to Buster, I was unable to use S3QL with any of my Amazon S3 buckets. All attempts to access gave errors like: ERROR: Can't connect to backend: unable to resolve hostname I was eventually able to track the problem down to a change in the format of the Amazon S3 URL which occurred two years ago. The new format of the URL is: s3: Note the addition of a "region" section in the URL. Unfortunately this change is not displayed by "apt-listchanges" during the upgrade, nor is it documented in the release notes. Please add this information to the release notes for Buster so that others don't waste hours trying to figure it out. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#930477: alltray disrupts GUI for application program it docks
Package: alltray Version: 0.71b-1+b2 Severity: important Dear Maintainer, When running the command: alltray zotero the zotero program is opened, successfully docks and appears normal, however, when you go to the system tray and display the zotero application window, dragging and dropping items between collections (folders) is broken. If zotero is launched outside of alltray, or launched instead using kdocker (the KDE equivalent of alltray), zotero has no problems. NOTES: - When attempting to drag and drop in zotero, the folder name you are dragging to becomes highlighted once you are aligned sufficiently to allow dropping. When run under alltray, this highlighting never occurs no matter where you position the item to be dropped, and dropping the item doesn't work. - In zotero, this drag/drop mechanism is the only method which can be used to copy or move items between the collection folders, so this completely breaks copy/move functionality. I have not noticed any other GUI issues when running zotero under alltray - Zotero version 5.0.66 - For people seeking a workaround, when using kdocker (at least in debian stretch), you need to use the "-n" option (which is not listed on the kdocker man page): kdocker -n Zotero zotero -- System Information: Debian Release: 9.9 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages alltray depends on: ii gconf-service3.2.6-4+b1 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgconf-2-4 3.2.6-4+b1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libx11-6 2:1.6.4-3+deb9u1 alltray recommends no packages. alltray suggests no packages. -- debconf-show failed
Bug#882792: Source of problem with missing icons
I found this bug report for the status notifier plugin: https://bugs.launchpad.net/ubuntu/+source/xfce4-statusnotifier-plugin/+bug/1756627 Which had the following note: "This happens if you have the package "ayatana-indicator-application" installed. Note that although it appears to be stealing the indicators, they don't show up in indicator-plugin instead." based on this I killed the process running the: "ayatana-indicator-application-service" with the following results: - As soon as the above process was killed, the Remmina icon appeared in the system tray. - The VLC icon (though it was running) did not appear after killing the above process, however, exiting and restarting VLC caused its icon to appear in the system tray as well. The difference in behavior of the two programs may be due to their using different frameworks (QT vs GTK). So it appears (at least for my case) this problem is due to the status notifier / ayatana-indicator-application problem in the above Ubuntu bug report. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | Biotechnology Development Services Telephone USA: +1 541-929-4089 | USA and the Netherlands Netherlands: +31 85 208 5570 | www.deatech.com
Bug#882792: xfce4-panel: some icons not appearing in notification panel
Package: xfce4-panel Version: 4.12.1-2 Followup-For: Bug #882792 Dear Maintainer, I am experiencing this problem as well. It started after I logged out and rebooted the system for the first time in many weeks (I'm not sure exactly how long). During that time many packages were installed / removed / upgraded, though I am not sure if any of them are relevant to the problem. Specifics: The following no longer display in the notification area, though they did before the reboot: vlc 3.0.2-0+deb remmina 1.2.30.1+dfsg-1~bpo9+1 The following all continue to work fine with the notification area: network-manager-gnome (nm-applet) 1.4.4-1 xfce4-clipman 2:1.4.1-1 hamster-applet 2.91.3+git2 alltray 0.71b-1+b2 Worthy of note, vlc is QT based and remmina is GTK based, so it appears the framework used may not matter. I have tried rebooting, reinstalling recently deleted packages, deleting recently installed packages, so far, nothing I can think of works. I didn't bother with some of the things that had been tried above. etckeeper is installed, and in reviewing the git log of package changes, I didn't see any obvious issues, though perhaps someone with a better knowledge of the notification area code might see something (a relevant library?), but the section of the log that might apply (after stripping extraneous commits) is about 800 lines long. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfce4-panel depends on: ii exo-utils0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libexo-1-0 0.10.7-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgarcon-1-00.4.0-2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libsm6 2:1.2.2-1+b3 ii libwnck222.30.7-5.1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util74.12.1-3 ii libxfconf-0-24.12.1-1 xfce4-panel recommends no packages. xfce4-panel suggests no packages. -- debconf-show failed
Bug#896005: synergy: Changing mouse xinput coordinate transform matrix breaks synergy
Package: synergy Version: 1.8.8-stable+dfsg.1-1 Severity: important Dear Maintainer, Issuing the following command either before or after starting synergys: xinput --set-prop "Coordinate Transformation Matrix" 3 0 0 0 3 0 0 0 1 Where is the ID given by "xinput --list" for my trackpoint mouse device. Results in the following problem(s): With the synergy client computer configured on the left side of my synergy server, synergy does one of the two following behaviors when sliding the mouse off the left side of the server screen: 1 - The mouse immediately wraps around to the right side of my server display rather than showing up on the client. 2 - The mouse is captured by the client display, but cannot be moved on the client, however, when in this state, keyboard input from the server is correctly routed to the client machine. Restoring the matrix to its default values on the server: xinput --set-prop "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1 fixes the problem. I also tested this with version 1.4.18 of synergy installed on both computers and experienced the same results. I flagged this as important since I am left with a choice of usable mouse performance (xinput scaling for proper acceleration on my trackpoint can only be achieved by use of the transform matrix) or working synergy. Additionally, the transform matrix is modified by some systems in order to get proper orientation of mouse output when using rotated screens. I tested a 90 degree rotation using the following matrix values: 0 -1 1 1 0 0 0 0 1 and synergy again broke. This problem makes synergy completely unusable in some working environments. Client machine used for this is running Ubuntu 16.04.4 LTS, xenial, with the Synergy 1.8.8 package installed from the Ubuntu "artful" archive. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages synergy depends on: ii libavahi-compat-libdnssd1 0.6.32-2 ii libc6 2.24-11+deb9u3 ii libcurl3-gnutls7.52.1-5+deb9u5 ii libgcc11:6.3.0-18+deb9u1 ii libqt4-network 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libssl1.1 1.1.0f-3+deb9u2 ii libstdc++6 6.3.0-18+deb9u1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii openssl1.1.0f-3+deb9u2 synergy recommends no packages. synergy suggests no packages. -- no debconf information
Bug#829300: - supplemental file
The attached file can be used to demonstrate the bug. - Select "not empty" for the Y column filter and the chart will display correctly, sorted by the X values. - Change the filter selection so all rows display again. This will make the chart return to its original incorrect display - Now select cells B8 - C11 and delete them with the option to move cells up. The chart will now display incorrectly in a different manner, even though the data has not changed and remains in the same order, only empty cells have been removed. - Other changes to the number of rows of empty cells can result different versions of the wrong display. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - Telephone: +1 541-929-4089 |- Natural Building Instruction - USA only: 800-467-5820 |www.deatech.com Chart-sort-by-X-bug.ods Description: bug example
Bug#829300: libreoffice-calc: Chart, x-y scatter with Sort by X values breaks with empty cells
Package: libreoffice-calc Version: 1:4.3.3-2+deb8u4 Severity: normal Dear Maintainer, I selected two columns of cells in a spreadsheet which had empty cells between the rows of data in these columns, however, a filter was turned on which displayed only the non-empty rows for these columns. I created an X-Y scatter plot with points and lines in calc, with the "Sort by X values" option and the chart was correctly created. Once the filter was turned off, displaying the empty cells, the points remained in the correct places, however, the order of the lines was rearranged so that the X sorting was no longer being correctly observed. I had naturally expected that the chart would not be affected by the filter being removed as only empty cells were added. Some experimentation has shown that it is not the filter, but some strange function of the number of empty cells between the rows that have data. With the filter turned off and just inserting and deleting empty rows I get different plots for the exact same data, given in the exact same order. I created a spreadsheet with nothing but the data being ploted and a chart and found that the order of the line plotting changed depending on the number of rows of empty cells between the different rows of data values. In other words, it does not just fail to sort the rows by the X value when there are empty cells, but the order it uses for the plot changes based on where and how many empty rows there are between the data values. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libreoffice-calc depends on: ii coinor-libcbc32.8.12-1 ii coinor-libcoinmp1 1.7.6+dfsg1-1 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u4 ii libgcc1 1:4.9.2-10 ii libicu52 52.1-8+deb8u3 ii liblcms2-22.6-3+b3 ii libmwaw-0.3-3 0.3.1-2 ii libodfgen-0.1-1 0.1.1-2 ii liborcus-0.8-00.7.0+dfsg-9 ii libreoffice-base-core 1:4.3.3-2+deb8u4 ii libreoffice-core 1:4.3.3-2+deb8u4 ii librevenge-0.0-0 0.0.1-3 ii libstdc++64.9.2-10 ii libwps-0.3-3 0.3.0-2 ii libxml2 2.9.1+dfsg1-5+deb8u2 ii lp-solve 5.5.0.13-7+b1 ii uno-libs3 4.3.3-2+deb8u4 ii ure 4.3.3-2+deb8u4 ii zlib1g1:1.2.8.dfsg-2+b1 libreoffice-calc recommends no packages. Versions of packages libreoffice-calc suggests: ii ocl-icd-libopencl1 2.2.3-1+deb8u1 Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.3 ii fonts-opensymbol 2:102.6+LibO4.3.3-2+deb8u4 ii libatk1.0-0 2.14.0-1 ii libboost-date-time1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u4 ii libcairo2 1.14.0-2.1+deb8u1 ii libclucene-contribs1 2.3.3.4-4 ii libclucene-core1 2.3.3.4-4 ii libcmis-0.4-4 0.4.1-7 ii libcups2 1.7.5-11+deb8u1 ii libcurl3-gnutls 7.38.0-4+deb8u3 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libeot0 0.01-3 ii libexpat1 2.1.0-6+deb8u3 ii libexttextcat-2.0-0 3.4.4-1 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+deb8u5 ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1 ii libglew1.10 1.10.0-3 ii libglib2.0-0 2.42.1-1+b1 ii libgltf-0.0-0 0.0.2-2 ii libglu1-mesa [libglu1]9.0.0-2 ii libgraphite2-31.3.6-1~deb8u1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libharfbuzz-icu0 0.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libhunspell-1.3-0 1.3.3-3 ii libhyphen02.8.8-1 ii libice6 2:1.0.9-1+b1 ii libicu52 52.1-8+deb8u3 ii libjpeg62-turbo 1:1.3.1-12 ii liblangtag1 0.5.1-3 ii liblcms2-22.6-3+b3 ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2 ii libmythes-1.2-0 2:1.2.4-1 ii libneon27-gnutls 0.30.1-1 ii libnspr4 2:4.10.7-1+deb8u1 ii libnspr4-0d 2:4.10.7-1+deb8u1 ii libnss3 2:3.17.2-1.1+deb8u2 ii libnss3-1d2:3.17.2-1.1+deb8u2 ii libodfgen-0.1-1 0.1.1-2 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-01.2.50-2+deb8u2 ii librdf0
Bug#771969: Workaround
On Tue, 9 Dec 2014, Nikolaus Rath wrote: As a workaround, could you use the attached program instead of mount.s3ql? It should work just like mount.s3ql, but it will retry on any kind of DNS error. I'm still planning to fix this properly (probably by not retrying on the first resolution attempt), but that is going to take a while. Thanks Nikolaus for this and all your efforts. It should be noted for anyone else who tries to use this wrapper around the mount program, it requires python3-dugong version 3.4 (currently in experimental), it throws an exception with the 3.3 version in testing: AttributeError: 'module' object has no attribute 'HostnameNotResolvable' I'm giving it try now which should be a good test of the code and local network as I'm moving about 400GB into an S3 file system. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Fri, 5 Dec 2014, Nikolaus Rath wrote: Shannon Dealy writes: [snip] Given the senario you were trying to fix with the change, perhaps a better approach would be to fail if initial resolution fails, but if the initial resolution succeeds, then the end point can reasonably be assumed to exist and future failures should keep retrying, at least for a substantial (possibly configurable) period of time. This provides the immediate feedback for manual or scripting related interactions, but once the file system is mounted focuses on maintaining/recovering the connection. Yes, that would be the best solution. It's just ugly to code, either way you to pass a "do_not_fail" parameter all the way from the main function to the low level network routines, or you have to do the first lookup on a higher level (which then needs to know details about all the storage backends). I would suggest that it should pass a timeout value rather than a "do_not_fail". This would give the application level code the greatest flexibility allowing for both immediate and short term failure settings as well as an effective "never fail" by just passing a ridiculously large value. Personally, I would love it if I could simply keep the file system mounted at all times, even when there is no network link, so that when there is a connection I can simply start using it, and when the connection goes away (even for a day or two), everything blocks and simply picks up where it left off when the connection returns. Well, that should actually work already. When there is no network connection, s3ql retries for a long amount. The problem only arises if there is partial connectivity. I tried it on the older version of the code I was using and it never recovered (not sure why). Don't know on the current version. Had another filesystem crash last night and while I can't say the exact series of events from the perspective of the file system, it was a complete network failure that crashed it (not just DNS). This would imply that perhaps the test is too sensitive right at the boundary of a network failure (perhaps some packets get through, but most don't) and needs to retry over a longer period of time before deciding if the failure is network or DNS. Upon further reflection: I looked over your dugong code and have given some thought to what little I know of the local network topology, and my guess is that your test for live DNS will always decide that DNS is up at my location whenever the network connection fails (though it is just a guess). The ISP appears to be in another country, and their local network in this building feeds about 500 rooms. It is likely they are using a local DNS caching server (for the building, city or country, doesn't really matter which) which responds from its cache with anything it knows about, and forwards all other requests up to the ISP's main servers. If that is the case, any time the network gets cut off between the local caching DNS server and the primary DNS servers, the test will fail because google.com will always resolve (since everyone uses it), but www.iana.org and C.root-servers.org will not since most internet users never have reason to do a direct lookup on the later two domains, and any recursive lookups of these domains as a result of a local query will always happen and be stored only at the primary server. Based on this, I would suggest that a more robust test would be to declare a DNS failure if any of the three lookups fail (after the host lookup previously failed). After all, a failure on any of these lookups would at least suggest a serious problem with the internet which is a reasonably likely cause of the initial host lookup failure. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Fri, 5 Dec 2014, Nikolaus Rath wrote: Shannon Dealy writes: On Thu, 4 Dec 2014, Nikolaus Rath wrote: Shannon Dealy writes: [snip] Unfortunately Linux does not provide an easy way to distinguish between an unavailable DNS server, and an un-resolvable host name. To distinguish these cases, S3QL/Dugong attempts to resolve a number of "test" hostnames. If these resolve, but the S3 hostname does not, S3QL/Dugong concludes that this hostname is not resolvable and terminates. Otherwise it assumes that the DNS server is currently not reachable and retries. Attempting to resolve hostnames on your system frequently fails (sometimes 3 times in a row), and sometimes it's apparently sufficiently flaky that 1. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved 2. Any of google.com, iana.org, or root-servers.net can be resolved 3. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved in this order, and without any waiting times. It occurs to me that the above can be problematic as a test under some senarios. When segmentation of the internet occurs, routing and DNS (from a given location) is often lost to some but not all major players. On a couple of occasions I have been unable to resolve google.com but could resolve debian.org, amazon.com and many other sites. I understand your approach and reasoning, and at the moment can't think of a better solution to what you are trying to do here, however, even if my network link and DNS server are running flawlessly, events can occur on the internet where where my connection will fail the above test. [snip] The relevant code in S3QL 2.2 was last touched in version 2.2, so I don't think that's it. However, relevant code in Dugong was last modified in version 3.2. Prior to 3.2, *any* DNS problem was considered temporary. In 3.2 and later, DNS problems are only considered temporary of *no* hostname can be resolved. The problem with the prior behavior was that it would permanently retry even in situations like this: mkfs.s3ql s3://mybucket.aws.s3.cmo Having this command block for any significant amount of time in the hope that the wrong hostname becomes resolvable was rather surprising, and people complained that their scripts would just hang instead of properly reporting an error. It seems for you the situation is the other way around... Which proves once again that you just can't win in life :-) Given the senario you were trying to fix with the change, perhaps a better approach would be to fail if initial resolution fails, but if the initial resolution succeeds, then the end point can reasonably be assumed to exist and future failures should keep retrying, at least for a substantial (possibly configurable) period of time. This provides the immediate feedback for manual or scripting related interactions, but once the file system is mounted focuses on maintaining/recovering the connection. Personally, I would love it if I could simply keep the file system mounted at all times, even when there is no network link, so that when there is a connection I can simply start using it, and when the connection goes away (even for a day or two), everything blocks and simply picks up where it left off when the connection returns. I often leave my sshfs mount connected this way as it recovers when the link returns. Of course my use-case may be different from others, I use it for maintaining laptop backups and access to data that won't fit on my laptop drive. This means that network connections come and go multiple times each day as I move between different locations, and stay down whenever I don't use the laptop for a few days. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Thu, 4 Dec 2014, Nikolaus Rath wrote: Shannon Dealy writes: [snip] Unfortunately Linux does not provide an easy way to distinguish between an unavailable DNS server, and an un-resolvable host name. To distinguish these cases, S3QL/Dugong attempts to resolve a number of "test" hostnames. If these resolve, but the S3 hostname does not, S3QL/Dugong concludes that this hostname is not resolvable and terminates. Otherwise it assumes that the DNS server is currently not reachable and retries. Attempting to resolve hostnames on your system frequently fails (sometimes 3 times in a row), and sometimes it's apparently sufficiently flaky that 1. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved 2. Any of google.com, iana.org, or root-servers.net can be resolved 3. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved in this order, and without any waiting times. At this point, S3QL thus assumes that your bucket ceased to exist and terminates. To avoid this, you'll have to fix the DNS resolution issues on your system. Maybe install a caching proxy nameserver like dnsmasq? While I can try dnsmasq as a solution, I was not having the degree of problems I am seeing under the old version of s3ql, and this is not the only network I connect to where I am seeing these problems. This could simply mean one or more of: - the network(s) have become more unstable (certainly possible) - that S3QL's test doesn't work quite the same way as before - there is a bug somewhere (S3QL or python libraries - I had to upgrade python to install the new S3QL) that makes it appear that DNS is still broken after it recovers - or something else is going on. I see in the log I sent you that a few failures were reported 10 minutes before S3QL gave up, but it is not clear to me if S3QL was able to resolve DNS names between these. Am I correct in assuming that there a timer as well as the three time in a row failure limit you mentioned? If not, there should be. Network failures often take a few minutes to resolve/recover so I would imagine the test should look something like: while failing and < 10 minutes (or possibly some configurable value) wait some short interval try again It is certainly not unusual to see short network glitches (DNS, connection loss, routing problems) lasting a few seconds to (rarely) a minute here, the five to ten minute DNS or general outage that I would view as a minimum before S3QL gives up is very uncommon (I pretty much live on the network when I am awake, so I am pretty sure I would notice problems of this level). Of course, I may be wrong, perhaps I should set up some kind of network monitor to see what kind of failure intervals there are. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Wed, 3 Dec 2014, Nikolaus Rath wrote: Hi, Is it possible that your DNS server behaves as described in https://bitbucket.org/nikratio/python-dugong/issue/16/? If so, could you test if upgrading to python3-dugong 3.4 from experimental fixes the problem? I installed python-dugong from experimental and proceeded to transfer a lot of data to my S3 file system. Stopped it a couple of times, unmounted once (successfully), remounted and continued transferring data. After around 13-15 GB total had been uploaded, the file system crashed again (no hang): rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on Transport endpoint is not connected (107) rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9] rsync: connection unexpectedly closed (51874 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9] See attached mount log file for more details. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com2014-12-04 22:21:27.735 31437:MainThread (name)s.determine_threads: Using 8 upload threads. 2014-12-04 22:21:27.738 31437:MainThread (name)s.main: Autodetected 4040 file descriptors available for cache entries 2014-12-04 22:21:36.322 31437:MainThread (name)s.get_metadata: Using cached metadata. 2014-12-04 22:21:36.325 31437:MainThread (name)s.main: Mounting filesystem... 2014-12-04 22:21:36.375 31445:MainThread (name)s.detach_process_context: Daemonizing, new PID is 31446 2014-12-05 00:18:35.346 31446:Thread-3 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... 2014-12-05 00:18:53.835 31446:Thread-10 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... 2014-12-05 00:18:58.710 31446:Thread-9 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... 2014-12-05 00:19:05.143 31446:Thread-4 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... 2014-12-05 00:19:13.463 31446:Thread-6 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... 2014-12-05 00:28:34.696 31446:Thread-10 (name)s.excepthook: Uncaught top-level exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 1445, in create_socket return socket.create_connection(address) File "/usr/lib/python3.4/socket.py", line 491, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): File "/usr/lib/python3.4/socket.py", line 530, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -2] Name or service not known During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook run_old(*args, **kw) File "/usr/lib/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib/s3ql/s3ql/block_cache.py", line 404, in _upload_loop self._do_upload(*tmp) File "/usr/lib/s3ql/s3ql/block_cache.py", line 431, in _do_upload % obj_id).get_obj_size() File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped return method(*a, **kw) File "/usr/lib/s3ql/s3ql/backends/common.py", line 258, in perform_write return fn(fh) File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 477, in __exit__ self.close() File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 471, in close self.fh.close() File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 636, in close self.fh.close() File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped return method(*a, **kw) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 845, in close headers=self.headers, body=self.fh) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 409, in _do_request query_string=query_string, body=body) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 642, in _send_request headers=headers, body=BodyFollowing(b
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Thu, 4 Dec 2014, Nikolaus Rath wrote: On 12/03/2014 11:44 PM, Shannon Dealy wrote: the file system still hangs (or the next time it hangs), could you follow the instructions at https://bitbucket.org/nikratio/s3ql/wiki/Providing%20Debugging%20Info to obtain a Python stacktrace, and attach it to this issue? This time the file system didn't hang until I attempted to unmount it. Attached are two log files with the mount and stack trace information. This looks odd. Did you issue both "setfattr -n fuse_stacktrace" *and* "kill -s USR1" commands? Yes, I didn't realize that the setfattr command was being used to trigger a one time event, I thought it was more like turning on a debug mode with extra info. If I am not mixing things up, I believe that initial setfattr was run right after mounting the file system, and the "kill -s USR1" was run when the file system was hung during the unmount, just before I did a kill -9 on mount.s3ql The attached files indicate both, and moreover, the number of active threads during the "kill -s USR1" command was much lower than during the "setfattr" command. How much time did pass between these commands (assuming that you issued both)? I don't recall. At least at the time that you issued the "kill" command, mount.s3ql was busy doing the SSL handshake with the remote server, so while it looked like it was hanging, it was probably waiting for the remote server. It had been waiting a very long time, though I don't remember exactly, for this case. I have limited the cache to 1GB so I don't have to wait too long if I need to kill a backup, pack up the computer and leave. Because of this, I know from past experience the maximum amount of time it takes to flush the cache and unmount using this network. I figure it is dead if the network has remained up, but network and cpu load for this process are minimal to zero and it has taken more than twice as long as it should for the unmount. In this case it should be done in 15 to 20 minutes max, so figure it had been at least twice that. Sorry I don't have a better answer. If you have a suggestion for a better way to tell if the filesystem is hung, it would be helpful. On one occasion I let a hung system sit for hours to see if it would recover (it didn't). Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772052: (s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system)
On Thu, 4 Dec 2014, Nikolaus Rath wrote: [snip] That's the reason for the exception on umount then. mount.s3ql currently isn't able to handle that. The existing data is ignored as you say, but mount.s3ql attempts to rmdir the cache directory after unmounting. That fails if there are still files in there. Normally, the only way for this directory to exist is if the file system was not unmounted cleanly. In this case mount.s3ql will refuse to start, and you have to run fsck.s3ql instead. fsck.s3ql will then clean-up the cache directory, and mount.s3ql will start with an empty cache. In your case... It should be noted that the fsck run on this file system was not run from my local machine, but from the remote server, so when I mount this on my local machine, it says something to the effect that the local cache is out of date, and then proceeds to download and unpack the current file system information from the remote server. .. you have neatly circumvented the clean-up of the cache directory. mount.s3ql now believes the file system is clean, but there is actually a cache directory with files in it. This is certainly a bug in S3QL, but I have to think about what the correct behavior for mount.s3ql actually would be. Refusing to mount would be odd, because the file system is indeed clean. But silently deleting the data in there intuitively sounds like a dangerous choice as well. While I don't know what is in the cache, it would seem to me that once the file system has been cleaned elsewhere that the cache data would cease to be usable for any purpose (other than forensic) as it would be inconsistent with the state of the file system. If so, I can't see that you have any real choice but to discard it. Informing the user that you have data available but they can't use it for anything would serve no purpose. You do provide warnings about multiple computers, including a warning when I run fsck on a computer which was not where the file system was last mounted. FWIW. At least this gives me a simple work-around for the bug :-) Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772052: (s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system)
On Thu, 4 Dec 2014, Nikolaus Rath wrote: On 12/04/2014 10:07 AM, Shannon Dealy wrote: Attached is the log file for a failed unmount. While my previous attempts were simple umount.s3ql commands, this time a couple of additional commands were run after rsync completed and before the umount: s3qlctrl flushcache /media/server-external s3qlctrl upload-meta /media/server-external umount.s3ql /media/server-external The logs looks as you also send a SIGUSR1 signal to mount.s3ql. Is that correct? No, it ran to completion on its own (though it took forever). I forgot to mention that I did issue this command just before running umount.s3ql setfattr -n fuse_stacktrace /media/server-external though I am not sure if that makes any difference with fuse as that command had previously been issued for that mount point when a different file system (the other one we have been debugging) was mounted there, and I have no idea if fuse retains this setting between unmounts and mounts on a given mount point. After the umount.s3ql command, what are the contents of /root/.s3ql/local:=2F=2F=2Fmedia=2FTransferDrive=2FS3QL_server-external-cache? Can you confirm that this directory did not exist when calling mount.s3ql? No, in fact based on the timestamps, I can confirm that this directory did exist as it has over 4000 files in it with November 30th timestamps spanning roughly 1/2 hour. I never gave this directory a thought as the mount indicates that the cache is out of date, so I assumed any old data that was lying around would be discarded when it downloads the current file system info. It should be noted that the fsck run on this file system was not run from my local machine, but from the remote server, so when I mount this on my local machine, it says something to the effect that the local cache is out of date, and then proceeds to download and unpack the current file system information from the remote server. I realize this discards any chance of recovering data that might have been transferred before the crash, but past experience has shown me that in most cases it is significantly faster to run fsck at the other end and resend the data. The problem is that fsck.s3ql is incredibly slow for my mounts using sshfs - well over an order of magnitude slower than my S3 mounts. Not sure what the issue is with s3ql over sshfs, the file system performance while a bit on the slow side seems reasonable until I try to fsck or umount the file system, then it takes forever (though maybe I just notice it more as that is a more interactive use of the file system). Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772052: (s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system)
Attached is the log file for a failed unmount. While my previous attempts were simple umount.s3ql commands, this time a couple of additional commands were run after rsync completed and before the umount: s3qlctrl flushcache /media/server-external s3qlctrl upload-meta /media/server-external umount.s3ql /media/server-external None displayed any errors at the command line level, but the end result was the same, next mount attempt indicated: File system damaged or not unmounted cleanly, run fsck! Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com2014-12-04 13:14:27.483 13515:MainThread (name)s.determine_threads: Using 8 upload threads. 2014-12-04 13:14:27.487 13515:MainThread (name)s.main: Autodetected 4040 file descriptors available for cache entries 2014-12-04 13:14:41.599 13515:MainThread (name)s.get_metadata: Ignoring locally cached metadata (outdated). 2014-12-04 13:14:42.226 13515:MainThread (name)s.get_metadata: Downloading and decompressing metadata... 2014-12-04 13:23:26.960 13515:MainThread (name)s.get_metadata: Reading metadata... 2014-12-04 13:23:26.965 13515:MainThread (name)s.restore_metadata: ..objects.. 2014-12-04 13:23:34.746 13515:MainThread (name)s.restore_metadata: ..blocks.. 2014-12-04 13:24:10.699 13515:MainThread (name)s.restore_metadata: ..inodes.. 2014-12-04 13:25:01.822 13515:MainThread (name)s.restore_metadata: ..inode_blocks.. 2014-12-04 13:26:16.473 13515:MainThread (name)s.restore_metadata: ..symlink_targets.. 2014-12-04 13:26:19.260 13515:MainThread (name)s.restore_metadata: ..names.. 2014-12-04 13:26:46.256 13515:MainThread (name)s.restore_metadata: ..contents.. 2014-12-04 13:29:10.849 13515:MainThread (name)s.restore_metadata: ..ext_attributes.. 2014-12-04 13:29:30.511 13515:MainThread (name)s.main: Setting cache size to 42007 MB 2014-12-04 13:29:30.513 13515:MainThread (name)s.main: Mounting filesystem... 2014-12-04 13:29:30.535 13870:MainThread (name)s.detach_process_context: Daemonizing, new PID is 13874 2014-12-04 15:01:30.236 13874:Metadata-Upload-Thread (name)s.run: Dumping metadata... 2014-12-04 15:01:30.240 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..objects.. 2014-12-04 15:01:33.701 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..blocks.. 2014-12-04 15:01:40.118 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..inodes.. 2014-12-04 15:02:22.569 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..inode_blocks.. 2014-12-04 15:02:45.095 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..symlink_targets.. 2014-12-04 15:02:45.892 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..names.. 2014-12-04 15:02:48.911 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..contents.. 2014-12-04 15:03:16.247 13874:Metadata-Upload-Thread (name)s.dump_metadata: ..ext_attributes.. 2014-12-04 15:03:17.194 13874:Metadata-Upload-Thread (name)s.run: Compressing and uploading metadata... 2014-12-04 15:06:19.607 13874:Metadata-Upload-Thread (name)s.run: Wrote 101 MiB of compressed metadata. 2014-12-04 15:06:19.609 13874:Metadata-Upload-Thread (name)s.run: Cycling metadata backups... 2014-12-04 15:06:19.609 13874:Metadata-Upload-Thread (name)s.cycle_metadata: Backing up old metadata... 2014-12-04 15:07:34.506 13874:Dummy-22 (name)s.stacktrace: # ThreadID: 140728286045952 pyapi.py:504, in stacktrace for filename, lineno, name, line in traceback.extract_stack(frame): # ThreadID: 140728294438656 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) queue.py:167, in get self.not_empty.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140729826797312 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) block_cache.py:399, in _upload_loop tmp = self.to_upload.get() block_cache.py:97, in get self.cv.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140728831309568 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) block_cache.py:677, in _removal_loop tmp = self.to_remove.get(block=len(ids)==0) queue.py:167, in get self.not_empty.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140728822916864 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_
Bug#772052: s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system
Package: s3ql Version: 2.11.1+dfsg-2 Severity: important Dear Maintainer, I have an s3ql file system on a remote server and access it via a local mount through sshfs. It worked fine with version 2.8.1, but since upgrading to to 2.11.1, umount.s3ql fails every time. Further, umount.s3ql does not report the failure, it appears to complete normally, so you only find out about the failure when you try to remount it and get an error: Using 8 upload threads. Autodetected 4040 file descriptors available for cache entries Enter file system encryption passphrase: Using cached metadata. File system damaged or not unmounted cleanly, run fsck! The mount log file does show that an exception occured while unmounting the file system, even though no error was reported on the command line (I would guess that technically it is mount.s3ql that throws the exception) I have tried this six or seven times after running fsck with the same result each time. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages s3ql depends on: ii fuse 2.9.3-9 ii libc6 2.18-4 ii libjs-sphinxdoc1.1.3+dfsg-4 ii libsqlite3-0 3.7.13-1+deb7u1 ii psmisc 22.19-1+deb7u1 ii python33.4.2-1 ii python3-apsw 3.8.6-r1-1 ii python3-crypto 2.6.1-5+b2 ii python3-defusedxml 0.4.1-2 ii python3-dugong 3.4+dfsg-1 ii python3-llfuse 0.40-2+b2 ii python3-pkg-resources 5.5.1-1 ii python3-requests 2.4.3-4 s3ql recommends no packages. s3ql suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On Wed, 3 Dec 2014, Nikolaus Rath wrote: severity 771969 important thanks Thanks for the report! I'll set the severity to important for now, because the package still works nicely for many other users. Not sure why it's making so much trouble for you.. Because computers hate me :-) I actually have yet another problem with an sshfs mounted s3ql file system but was trying to get the issues with my S3 mount resolved first. but I notice that (like the last bug you found) this seems related to the handling of unreliable network connections. In this case there seems to be a temporary problem with your DNS server which S3QL has trouble coping with. From a high level perspective, the connection (generally) is pretty reliable, but I wouldn't notice momentary network issues. The raw_streamXXX files are from the patch that you applied to the debug the previous issue. I'd recommend to purge and reinstall both the s3ql and python3-dugong packages to make sure that you're in vanilla state again. I forgot about the dugong patch, so I reinstalled both packages, using the Debian-unstable version for s3ql If the file system still hangs (or the next time it hangs), could you follow the instructions at https://bitbucket.org/nikratio/s3ql/wiki/Providing%20Debugging%20Info to obtain a Python stacktrace, and attach it to this issue? This time the file system didn't hang until I attempted to unmount it. Attached are two log files with the mount and stack trace information. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com2014-12-04 07:28:56.413 31144:MainThread (name)s.excepthook: Mountpoint does not exist. 2014-12-04 07:39:43.743 609:MainThread (name)s.determine_threads: Using 8 upload threads. 2014-12-04 07:39:43.746 609:MainThread (name)s.main: Autodetected 4040 file descriptors available for cache entries 2014-12-04 07:39:56.730 609:MainThread (name)s.get_metadata: Using cached metadata. 2014-12-04 07:39:56.734 609:MainThread (name)s.main: Mounting filesystem... 2014-12-04 07:39:56.821 626:MainThread (name)s.detach_process_context: Daemonizing, new PID is 630 2014-12-04 07:42:45.765 630:MainThread (name)s.main: FUSE main loop terminated. 2014-12-04 07:42:45.786 630:MainThread (name)s.unmount: Unmounting file system... 2014-12-04 07:42:46.272 630:MainThread (name)s.main: File system unchanged, not uploading metadata. 2014-12-04 07:42:46.309 630:MainThread (name)s.main: Cleaning up local metadata... 2014-12-04 07:42:51.966 630:MainThread (name)s.main: All done. 2014-12-04 07:42:58.936 3663:MainThread (name)s.determine_threads: Using 8 upload threads. 2014-12-04 07:42:58.938 3663:MainThread (name)s.main: Autodetected 4040 file descriptors available for cache entries 2014-12-04 07:43:05.572 3663:MainThread (name)s.get_metadata: Using cached metadata. 2014-12-04 07:43:05.582 3663:MainThread (name)s.main: Mounting filesystem... 2014-12-04 07:43:05.602 3669:MainThread (name)s.detach_process_context: Daemonizing, new PID is 3671 2014-12-04 07:43:12.769 3671:Dummy-22 (name)s.stacktrace: # ThreadID: 140042022409984 pyapi.py:504, in stacktrace for filename, lineno, name, line in traceback.extract_stack(frame): # ThreadID: 140042039195392 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) queue.py:167, in get self.not_empty.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140043138082560 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) block_cache.py:677, in _removal_loop tmp = self.to_remove.get(block=len(ids)==0) queue.py:167, in get self.not_empty.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140042576066304 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) block_cache.py:677, in _removal_loop tmp = self.to_remove.get(block=len(ids)==0) queue.py:167, in get self.not_empty.wait() threading.py:290, in wait waiter.acquire() # ThreadID: 140043154867968 threading.py:888, in _bootstrap self._bootstrap_inner() threading.py:920, in _bootstrap_inner self.run() mount.py:66, in run_with_except_hook run_old(*args, **kw) threading.py:868, in run self._target(*self._args, **self._kwargs) block_cache.py:677, in _removal_loop tmp = self.to_remove.get(blo
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Package: s3ql
Version: 2.11.1+dfsg-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I mounted an S3QL file system and ran rsync to transfer data to the file
system. After a few minutes I noticed the rsync process was no longer
scanning the file system or transfering data. Ctrl-C would not terminate
the rsync (presumably locked in some I/O transaction). mount.s3ql appears
hung and I could not unmount the file system.
The mount log file (see below) showed an exception had been thrown and
my .s3ql directory has about 600 raw_streamXXX files in it.
I killed everything, ran fsck on the file system, remounted and tried again
with the same result.
Contents of mount.log:
2014-12-03 23:17:03.472 23261:MainThread (name)s.determine_threads: Using 8
upload threads.
2014-12-03 23:17:03.473 23261:MainThread (name)s.main: Autodetected 4040 file
descriptors available for cache entries
2014-12-03 23:17:12.025 23261:MainThread (name)s.get_metadata: Using cached
metadata.
2014-12-03 23:17:12.029 23261:MainThread (name)s.main: Mounting filesystem...
2014-12-03 23:17:12.043 23269:MainThread (name)s.detach_process_context:
Daemonizing, new PID is 23270
2014-12-03 23:20:46.372 23270:Thread-18 (name)s._parse_xml_response: Server did
not provide Content-Type, assuming XML
2014-12-03 23:21:21.816 23270:Thread-18 (name)s.excepthook: Uncaught top-level
exception:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook
run_old(*args, **kw)
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/s3ql/s3ql/block_cache.py", line 684, in _removal_loop
backend.delete_multi(['s3ql_data_%d' % i for i in ids])
File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 273, in delete_multi
return self.backend.delete_multi(keys, force=force)
File "/usr/lib/s3ql/s3ql/backends/s3.py", line 81, in delete_multi
self._delete_multi(tmp, force=force)
File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped
return method(*a, **kw)
File "/usr/lib/s3ql/s3ql/backends/s3.py", line 116, in _delete_multi
resp = self._do_request('POST', '/', subres='delete', body=body,
headers=headers)
File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 409, in _do_request
query_string=query_string, body=body)
File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 638, in _send_request
self.conn.send_request(method, path, body=body, headers=headers)
File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 484, in
send_request
self.timeout)
File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 1373, in
eval_coroutine
if not next(crt).poll(timeout=timeout):
File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 511, in
co_send_request
self.connect()
File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 410, in connect
self._sock = socket.create_connection((self.hostname, self.port))
File "/usr/lib/python3.4/socket.py", line 491, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
File "/usr/lib/python3.4/socket.py", line 530, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages s3ql depends on:
ii fuse 2.9.3-9
ii libc6 2.18-4
ii libjs-sphinxdoc1.1.3+dfsg-4
ii libsqlite3-0 3.7.13-1+deb7u1
ii psmisc 22.19-1+deb7u1
ii python33.4.2-1
ii python3-apsw 3.8.6-r1-1
ii python3-crypto 2.6.1-5+b2
ii python3-defusedxml 0.4.1-2
ii python3-dugong 3.3+dfsg-2
ii python3-llfuse 0.40-2+b2
ii python3-pkg-resources 5.5.1-1
ii python3-requests 2.4.3-4
s3ql recommends no packages.
s3ql suggests no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On Tue, 2 Dec 2014, Shannon Dealy wrote: [snip] I performed a capture as requested, ... Sorry Nikolaus, I have deleted that file from where I posted it. I made a mistake, that file was captured with ssl enabled. In fact, it appears based on a limited sample, that fsck.s3ql fails 100% of the time when ssl is enabled (35+ runs), and succeeds 100% of the time when ssl is disabled (6 runs so far). I don't know if this is a generic work around, or if it just happens to work this way for my particular data set. Given the above, there is no way I can provide you with a "no-ssl" version of the captured data (since it always succeeds). Could you make a patch to fsck.s3ql which would provide you with the required data? Or does the difference between ssl and no-ssl behavior give you some ideas? Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On Mon, 1 Dec 2014, Nikolaus Rath wrote: severity -1 normal retitle -1 fsck.s3ql sporadically crashes when checking objects thanks Retitling this bug and lowering severity for now. I don't think that the mount.s3ql crash is related to the fsck.s3ql crashes, or that there is any data corruption. While I understand your assessment, I don't think I would characterize this bug as "normal". Based on my understanding, the Debian guidelines would rate this bug at the very least as "important", and frankly I would still argue for "critical" given that it effectively "causes serious data loss" (one of the possible criteria for "critical"). My reasoning is that even assuming the file system data has not actually been lost or corrupted (and I believe you are likely correct in this), I ran fsck.s3ql roughly 30 times before getting a successful run. There is nothing to indicate that someone else with similar circumstances would not have to run it 1000 or 100,000 more times in order to recover the file system. For such a case, their data is unavailable to them and effectively 100% lost until they have a fixed version of fsck.s3ql FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On Mon, 1 Dec 2014, Nikolaus Rath wrote: [snip] I still have the bucket that was copied using the aws command line tools, and am in the process of copying that to a new bucket for testing so we don't lose the corrupt version, but won't get to testing it tonight. I have not tried to use the original file system since fsck.s3ql succeeded and am not entirely sure if it trust it without knowing what was wrong with fsck.s3ql At this point, I am pretty confident that this is a bug related to object listing. Object listing is only used by fsck.s3ql, so I think that using the file system normally (aka with mount.s3ql) should not result in any problems. My concern was not with the basic file system and mount.s3ql, but rather with whether or not fsck.s3ql had correctly reconstructed the file system after the failure given that there is (at least on occasion), a bug in it's handling of some of the file system data. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On Mon, 1 Dec 2014, Nikolaus Rath wrote: [snip] I think at this point I can probably write you a patch to get the file system functional again, but I'd very much like to find out what's happening here. Would you be able to run fsck with --backend-options no-ssl, and capture the traffic using Wireshark? Hi Nikolaus, I performed several runs of fsck.s3ql while experimenting with wireshark (it has been years since I've used it or tcpdump) to get the settings right. Each time, fsck.s3ql failed in the same manner. Then when I did what was to be the final run/capture, it ran to completion without errors. Given the behavior above, the first thing that leaps to mind is possibly a race condition. I would usually expect more inconsistency (such as failing at different objects each time) if it was simply uninitialized data or corruption, though those may be possibilities too. I still have the bucket that was copied using the aws command line tools, and am in the process of copying that to a new bucket for testing so we don't lose the corrupt version, but won't get to testing it tonight. I have not tried to use the original file system since fsck.s3ql succeeded and am not entirely sure if it trust it without knowing what was wrong with fsck.s3ql Something more for you to ponder. FWIW. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Copied bucket
On Sun, 30 Nov 2014, Nikolaus Rath wrote: On 11/30/2014 12:50 AM, Shannon Dealy wrote: I suspect this is because you copied the objects into a new bucket, but did not include the associated metadata. Which tool did you use to do the copy, and how did you call it? I used the AWS command line tools: aws s3 sync s3://src-bucket s3://dest-bucket It did fail part way through the transfer, so I restarted it with the same command. When you use the S3 Management Console (https://console.aws.amazon.com/s3/home) to look at the "s3ql_metadata" object in the original bucket and the copy, does it have the same metadata? While the s3ql_metadata file is there, in the new bucket it is missing all of the keys except the Content-Type. Not sure whether this means the fsck without cached data trashed it, or if amazon's sync was trashing the transfered data because I used it incorrectly or it is broken somehow. I think you have to blame the aws tool for this one. If you think fsck.s3ql is at fault, that's easy enough to check: just run the sync command again and see if the metadata is present before running fsck.s3ql. I don't know if that's a bug in aws, or if you're using it incorrectly, but "gsutil" is able to copy buckets including metadata (in case you want to try that). Poking around, it appears that the metadata was lost only on the s3ql_metadata files, so I deleted them and ran the "aws s3 sync" command again. The new files again were missing the metadata, so I just copied the 13 s3ql_metadata files using the aws console, and this time the metadata was preserved. I didn't see anything special about these files with regard to permissions or other information, is there anything special about how these files are created/stored on S3? If not, then possibly simply having "metadata" in the filename may cause the aws s3 sync command to lose the file metadata. In any case, once I replaced the s3ql_metadata files I was able to run fsck.s3ql on the copy of the file system bucket without the local data cache and it resulted in exactly the same failure mode/exception "PRIMARY KEY must be unique". Will take a look at gsutil, thanks for the suggestion. FWIW. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: Copied bucket
I suspect this is because you copied the objects into a new bucket, but did not include the associated metadata. Which tool did you use to do the copy, and how did you call it? I used the AWS command line tools: aws s3 sync s3://src-bucket s3://dest-bucket It did fail part way through the transfer, so I restarted it with the same command. When you use the S3 Management Console (https://console.aws.amazon.com/s3/home) to look at the "s3ql_metadata" object in the original bucket and the copy, does it have the same metadata? While the s3ql_metadata file is there, in the new bucket it is missing all of the keys except the Content-Type. Not sure whether this means the fsck without cached data trashed it, or if amazon's sync was trashing the transfered data because I used it incorrectly or it is broken somehow. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
On Sat, 29 Nov 2014, Nikolaus Rath wrote: On 11/29/2014 09:49 AM, Shannon Dealy wrote: Package: s3ql Version: 2.11.1+dfsg-1 Severity: critical Justification: causes serious data loss Dear Maintainer, While running rsync to backup data to an s3ql file system mounted from Amazon's S3 services, the internet connection failed, resulting in the following [snip] Chances are good that this can be done, so don't give up hope yet. Best, -Nikolaus Attached are both the mount and fsck log files, stripped of data from other (irrelevent) sessions and with slight mods to remove references to my S3 file system info (bucket/prefix). I have left the original bucket and local cache unmodified except for whatever changes occured during my fsck attempt in case they can be of use in debugging this. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com |- Custom Software Development - USA Phone: +1 800-467-5820 |- Natural Building Instruction - numbers : +1 541-929-4089 |www.deatech.com2014-11-28 18:08:52.029 31159:MainThread (name)s.determine_threads: Using 8 upload threads. 2014-11-28 18:08:52.032 31159:MainThread (name)s.main: Autodetected 4040 file descriptors available for cache entries 2014-11-28 18:09:00.435 31159:MainThread (name)s.get_metadata: Using cached metadata. 2014-11-28 18:09:00.439 31159:MainThread (name)s.main: Mounting filesystem... 2014-11-28 18:09:00.448 31163:MainThread (name)s.detach_process_context: Daemonizing, new PID is 31167 2014-11-29 02:14:44.787 31167:Thread-9 (name)s.wrapped: Encountered ConnectionTimedOut exception (send/recv timeout exceeded), retrying call to ObjectW.close for the 3-th time... 2014-11-29 10:49:36.636 31167:Thread-10 (name)s.excepthook: Uncaught top-level exception: Traceback (most recent call last): File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook run_old(*args, **kw) File "/usr/lib/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib/s3ql/s3ql/block_cache.py", line 404, in _upload_loop self._do_upload(*tmp) File "/usr/lib/s3ql/s3ql/block_cache.py", line 431, in _do_upload % obj_id).get_obj_size() File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped return method(*a, **kw) File "/usr/lib/s3ql/s3ql/backends/common.py", line 258, in perform_write return fn(fh) File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 477, in __exit__ self.close() File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 471, in close self.fh.close() File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 636, in close self.fh.close() File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped return method(*a, **kw) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 845, in close headers=self.headers, body=self.fh) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 409, in _do_request query_string=query_string, body=body) File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 642, in _send_request headers=headers, body=BodyFollowing(body_len)) File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 477, in send_request self.timeout) File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 1361, in eval_coroutine if not next(crt).poll(timeout=timeout): File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 504, in co_send_request self.connect() File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 408, in connect self._sock = socket.create_connection((self.hostname, self.port)) File "/usr/lib/python3.4/socket.py", line 509, in create_connection raise err File "/usr/lib/python3.4/socket.py", line 500, in create_connection sock.connect(sa) OSError: [Errno 113] No route to host 2014-11-29 10:50:11.907 31167:Thread-9 (name)s.exchook: Unhandled top-level exception during shutdown (will not be re-raised) 2014-11-29 10:50:11.907 31167:Thread-9 (name)s.excepthook: Uncaught top-level exception: Traceback (most recent call last): File "/usr/lib/s3ql/s3ql/mount.py", line 66, in run_with_except_hook run_old(*args, **kw) File "/usr/lib/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib/s3ql/s3ql/block_cache.py", line 404, in _upload_loop self._do_upload(*tmp) File "/usr/lib/s3ql/s3ql/block_cache.py", line 431, in _do_upload % obj_id).get_obj_size() File "/usr/lib/s3ql/s3ql/backends/common.py", line 46, in wrapped return method(*a, **kw) File "/usr/lib/s3ql/s3ql/backends/common.py", line 258, in perform_write return fn(fh) File "/usr/lib/s3ql/s3ql/backends/comprenc.py
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
Package: s3ql
Version: 2.11.1+dfsg-1
Severity: critical
Justification: causes serious data loss
Dear Maintainer,
While running rsync to backup data to an s3ql file system mounted from Amazon's
S3 services, the internet connection failed, resulting in the following
error(s) from rsync:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken
pipe (32)
rsync: write failed on "": Software caused connection
abort (103)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (17298 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605)
[sender=3.0.9]
I attempted to unmount the file system with the following result (twice):
# umount.s3ql /media/server-external
File system appears to have crashed.
I then forced it to unmount as follows:
# fusermount -u -z /media/server-external
Then attempted to fsck the file system (twice - both gave the same result):
fsck.s3ql s3:///
Enter file system encryption passphrase:
Starting fsck of s3:///
Using cached metadata.
Remote metadata is outdated.
Checking DB integrity...
Creating temporary extra indices...
Checking lost+found...
Checking cached objects...
Committing block 14 of inode 442809 to backend
Committing block 16 of inode 442809 to backend
Committing block 17 of inode 442809 to backend
Committing block 15 of inode 442809 to backend
Committing block 19 of inode 442809 to backend
Committing block 18 of inode 442809 to backend
Checking names (refcounts)...
Checking contents (names)...
Checking contents (inodes)...
Checking contents (parent inodes)...
Checking objects (reference counts)...
Checking objects (backend)...
..processed 10 objects so far..
Dropping temporary indices...
Uncaught top-level exception:
Traceback (most recent call last):
File "/usr/bin/fsck.s3ql", line 9, in
load_entry_point('s3ql==2.11.1', 'console_scripts', 'fsck.s3ql')()
File "/usr/lib/s3ql/s3ql/fsck.py", line 1189, in main
fsck.check()
File "/usr/lib/s3ql/s3ql/fsck.py", line 85, in check
self.check_objects_id()
File "/usr/lib/s3ql/s3ql/fsck.py", line 848, in check_objects_id
self.conn.execute('INSERT INTO obj_ids VALUES(?)', (obj_id,))
File "/usr/lib/s3ql/s3ql/database.py", line 98, in execute
self.conn.cursor().execute(*a, **kw)
File "src/cursor.c", line 231, in resetcursor
apsw.ConstraintError: ConstraintError: PRIMARY KEY must be unique
Next I copied the entire Amazon bucket to a new bucket and attempted an fsck
on the copy, minus the locally cached file system data:
# fsck.s3ql s3:///
Enter file system encryption passphrase:
Starting fsck of s3:///
Uncaught top-level exception:
Traceback (most recent call last):
File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 381, in
_convert_legacy_metadata
meta_new['data'] = meta['data']
KeyError: 'data'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/fsck.s3ql", line 9, in
load_entry_point('s3ql==2.11.1', 'console_scripts', 'fsck.s3ql')()
File "/usr/lib/s3ql/s3ql/fsck.py", line , in main
param = backend.lookup('s3ql_metadata')
File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 72, in lookup
meta_raw = self._convert_legacy_metadata(meta_raw)
File "/usr/lib/s3ql/s3ql/backends/comprenc.py", line 383, in
_convert_legacy_metadata
raise CorruptedObjectError('meta key data is missing')
s3ql.backends.common.CorruptedObjectError: meta key data is missing
NOTE: I'm not sure about the exact implication of "_convert_legacy_metadata"
in the traceback above, but this was NOT a legacy file system, it was
just created using s3ql 2.11.1 as it is cheaper to rebuild it than
to pull 700 GB in the old copy down from Amazon to do the "verify"
specified as part of the upgrade procedure from older versions.
At the time of this failure I had uploaded between 200 and 300 GB of
deduplicated/compressed data to the new file system.
As things currently stand, unless I have overlooked or misunderstood something
(which I consider entirely possible), this network connection failure has
resulted in 100% data loss unless fsck can be fixed in a manner which will
allow it to complete correctly and recover the file system data. As I
maintain other backups, no actual data has been lost (so far), but this
makes s3ql unsafe to use and further attempts to backup my data to S3
pointless.
Regards,
Shannon Dealy
-- Syste
Bug#747850: xfce4 incorrectly stores session configuration in .cache directory
Package: xfce4 Version: 4.8.0.3 Severity: normal Dear Maintainer, xfce4 is currently storing session information under $HOME/.cache/sessions when at least some of this information should be stored somewhere under $HOME/.config/ instead. Cache directories historically were intended for data which the program could either regenerate or reload from external sources, so cache folders could be deleted (or in my case not backed up) without data loss. An example of this for "/var/cache" from the Filesystem Hierarchy Standard: "/var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss" I do realize that FHS does not cover the $HOME/.cache directories however, their definition is consistent with the historical meaning and usage of "cache" directories. XDG which does define the standard for these directories gives a much more vague definition of: "defines the base directory relative to which user specific non-essential data files should be stored." however, I would still interpret "non-essential" files as those which would meet the FHS definition above. As a saved session cannot be recovered by the program if $HOME/.cache is lost, the user must manually rebuild the lost session layout (which in my case takes about 10 minutes). This appears to violate the purpose of the $HOME/.cache directory. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfce4 depends on: ii gtk2-engines-xfce 2.8.1-3 ii orage 4.8.3-2 ii thunar 1.2.3-4+b1 ii xfce4-appfinder4.8.0-3 ii xfce4-mixer4.8.0-3+b1 ii xfce4-panel4.8.6-4 ii xfce4-session 4.8.3-3 ii xfce4-settings 4.8.3-2 ii xfce4-utils4.8.3-2 ii xfconf 4.8.1-1 ii xfdesktop4 4.8.3-2 ii xfwm4 4.8.3-2 Versions of packages xfce4 recommends: ii desktop-base 7.0.3 ii tango-icon-theme 0.8.90-5 ii thunar-volman 0.6.1-1 ii xfce4-notifyd 0.2.2-2 ii xorg 1:7.7+3~deb7u1 Versions of packages xfce4 suggests: ii xfce4-goodies 4.8.2 ii xfprint4 4.6.1-3 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739038: quitcount: Can't exit program
Package: quitcount Version: 2.0-1 Severity: normal Dear Maintainer, When quitcount starts, it shows up on my xfce4 panel. When I right click on the icon, a menu is displayed, when I click "quit", the program doesn't quit. It appears the only way out is to use "kill" from the command line. I tried running quitcount from an xterm and then clicking on "quit" this resulted in the following error being displayed in the xterm: (quitcount:5459): Gtk-CRITICAL **: gtk_main_quit: assertion `main_loops != NULL' failed -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quitcount depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u1 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-7 ii libpango1.0-0 1.30.0-1 quitcount recommends no packages. quitcount suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739037: quitcount: Auto-starts for all users
Package: quitcount Version: 2.0-1 Severity: normal Dear Maintainer, quitcount automatically starts up whenever any user logs in. This ignores the fact that many system users may not want quitcount to run, or more importantly that no system user wants to run it. quitcount was automatically installed on my system because I have the med-tools task installed. The next time I logged in, I was greeted with the quitcount configuration screen. This should not happen to any user who has not explicitly chosen to have quitcount run for their account. -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages quitcount depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u1 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-7 ii libpango1.0-0 1.30.0-1 quitcount recommends no packages. quitcount suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
Hi Moritz, I have not seen this problem or any of the other iwl instabilities in a long time, however, I have been running with these option lines disabling 11n functionality in order to achieve that stability: options iwlagn 11n_disable50=1 options iwlwifi 11n_disable=1 since I am no longer running kernels which use iwlagn (currently running 3.2.xx), I can't really speak to the original issue anymore. Of course iwlwifi has had 11n related stability issues as well, however, I have never seen the: "MAC is in deep sleep" bug (as far as I can recall) while running a newer kernel with iwlwifi instead of iwlagn. Not sure how much code (if any) is common between iwlwifi and the older iwlagn module. I suppose I should try enabling 11n again to see what happens (I had forgotten it was disabled). The upgrade to wheezy is most notable for much shorter times required to make wireless connections, though I am not sure if it is the driver or network-manager responsible for that improvement. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com On Thu, 15 Aug 2013, Moritz Muehlenhoff wrote: reassign 628444 src:linux thanks On Wed, Mar 14, 2012 at 08:37:17PM -0700, Shannon Dealy wrote: Like others, the problems seemed to start around 2.6.39. Thought I should note here, my system showed this problem with 2.6.36 through 2.6.39. It seems to have stopped showing the problem (possibly due to a memory upgrade many months ago), but it still has chronic instability of the connection (drops out for varying intervals), and often, network-manager doesn't seem aware of the failure - reloading the driver isn't a reliable solution (sometimes appears to work, often does not) Does this bug still occur with more recent kernels/firmware, e.g. Wheezy? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703851: scim: SCIM causes applications (gnucash, epiphany, ...) to segfault
Package: scim Version: 1.4.13-5 Severity: normal Dear Maintainer, SCIM causes segmentation faults in applications in two distinct senarios, both related to having scim-tables-XX installed. It appears that simply having scim-modules-table installed alone is not sufficient to cause either issue (though it may be where the problem lies). 1 - Having any scim-tables-XX installed will cause a segmentation fault when exiting gnucash, epiphany browser and presumably other programs. Most people wouldn't notice this unless they happened to launch the program from the command line since (so far) I haven't seen any side effects from this senario. 2 - Having any scim-tables-XX installed, run SCIM setup, select Global setup under IMEngine, then disable any table(s) that are not in the "Other" list (e.g. the "Japanese" group or "Nippon" individual table). At this point attempting to launch gnucash or epiphany will segfault during startup of these programs. Things to note: - The scim daemon does not need to be running when launching the program for these problems to occur. - I have tried this with a variety of other tables installed instead of Japanese, the result is always the same. - Purging and reinstalling scim and all its pieces had no effect - Discarding my old SCIM configuration and configuring from scratch had no effect. Work-around: - Only install tables that are needed and don't disable any of them. This still leaves a potential problem for segfault on exit. NOTE: I'm a bit wary of saying that the segfault at exit issue doesn't actually cause any problems with the applications that use it, only that I haven't seen any. My guess is that it would depend on what order the application code does its cleanup and shutdown. If state saving / file updates are done before wrapping up with SCIM they are probably fine, if SCIM is wrapped up first, there is a chance of data loss. So I would expect that it will depend on the particular application as to whether or not there are problems with using the obvious workaround above. -- Package-specific info: Related packages: ii libscim8c2a:i3 1.4.13-5 i386 library for SCIM platform ii scim 1.4.13-5 i386 smart common input method platfor ii scim-gtk-immod 1.4.13-5 i386 GTK+ input method module with SCI ii scim-modules-s 1.4.13-5 i386 socket modules for SCIM platform ii scim-modules-t 0.5.9-2 i386 generic tables IM engine module f ii scim-tables-ja 0.5.9-2 all Japanese input method data tables Related environment variables: $XMODIFIERS=@im=SCIM $GTK_IM_MODULE=scim $QT_IM_MODULE=xim Installed SCIM components: /usr/lib/scim-1.0: 1.4.0 scim-helper-launcher scim-helper-manager scim-launcher scim-panel-gtk /usr/lib/scim-1.0/1.4.0: Config Filter FrontEnd Helper IMEngine SetupUI /usr/lib/scim-1.0/1.4.0/Config: simple.so /usr/lib/scim-1.0/1.4.0/Filter: sctc.so /usr/lib/scim-1.0/1.4.0/FrontEnd: x11.so /usr/lib/scim-1.0/1.4.0/Helper: setup.so /usr/lib/scim-1.0/1.4.0/IMEngine: rawcode.so table.so /usr/lib/scim-1.0/1.4.0/SetupUI: aaa-frontend-setup.so aaa-imengine-setup.so panel-gtk-setup.so table-imengine-setup.so -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages scim depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-6 ii libltdl72.4.2-1.1 ii libpango1.0-0 1.30.0-1 ii libscim8c2a 1.4.13-5 ii libstdc++6 4.7.2-5 ii libx11-62:1.5.0-1 Versions of packages scim recommends: ii im-switch 1.23 pn scim-bridge-agent ii scim-gtk-immodule 1.4.13-5 Versions of packages scim suggests: pn scim-anthy pn scim-canna pn scim-chewing pn scim-hangul pn scim-m17n pn scim-pinyin pn scim-prime pn scim-skk pn scim-tables-additional ii scim-tables-ja 0.5.9-2 pn scim-tables-ko pn scim-tables-zh pn scim-thai pn scim-uim -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
On Fri, 16 Mar 2012, Bjørn Mork wrote: Shannon Dealy writes: I created a file "/etc/modprobe.d/iwlagn.conf" and placed the following line in it: options iwlagn 11n_disable=1 11n_disable50=1 Note that the 11n_disable50 options was removed in 3.0 and the iwlagn module was renamed to iwlwifi in 3.2. Unfortunate, since further testing shows that it is the 11n_disable50=1 that matters. Disabling either of the above options makes my link stable, and since 11n_disable=1 would effectively cause "11n_disable50" to happen as well, the implication is that the problem is in the code which is/was controlled by the 11n_disable50. Would be nice if anyone can confirm if this fixes the deep sleep problem as well. Which makes this workaround pretty much irrelevant to any current Debian kernel as noone(?) has seen the bug in 2.6.32. While it may not be relevant to you, it is completely relevant in that it: - provides developers with a narrowed range of places to look for the problem in all versions of the kernel/driver code, including those were the option was removed (they can easily check what part of the code it previously disabled) - using just the 11n_disable option should still solve the stability problems I am seeing and possibly the deep sleep as well (need confirmation on that) for people running 3.x (though granted it is not a great workaround given the performance hit) - I assume you are speaking with regard to 2.6.32 being the default stable kernel so it won't affect people running stock Debian stable? I don't recall seeing confirmation from anyone that the problem went away by downgrading to 2.6.32. Are you still using the 2.6.39-1 kernel you originally opened this bug against? [snip] Yes, though it has been rebuilt for debug tracing of the iwlagn driver. Unfortunately I can't afford the down time right now that a kernel upgrade beyond 2.6.39 would entail (other software would have to be upgraded and that might require that I write some code as well to deal with the kernel changes). I also can't downgrade to 2.6.32 (assuming that it would make any difference) as it doesn't support some of my hardware. FWIW Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
Found these two pages discussing what appears to be the same problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575492
http://ubuntuforums.org/showthread.php?t=1470820
in at least one case, it is definitely the same problem ("deep sleep"
message shows up in the posted log). Note: while there were Lenovo
computers, there were a number of other brands also having problems.
Wireless card in the discussion was the Intel 5100 AGN.
I created a file "/etc/modprobe.d/iwlagn.conf" and placed the following
line in it:
options iwlagn 11n_disable=1 11n_disable50=1
and reloaded my driver. Wireless has been rock solid for 14 hours, no
dropped packets, no long pauses, no mysterious disconnects. Normally I
would at least see short pauses, a few disconnects and 100's of dropped
packets in this time frame.
Since I haven't been seeing the "deep sleep" problem lately, someone else
will have to disable "N" on their system to test if this prevents that
issue.
This doesn't really constitute a fix and it isn't a great work-around
either given the major lost of network performance, but if it works for
others, it would significantly narrow the range of possible causes for
the problem.
Shannon C. Dealy | DeaTech Research Inc.
de...@deatech.com | - Custom Software Development -
Phone: (800) 467-5820 | - Natural Building Instruction -
or: (541) 929-4089 | www.deatech.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
Like others, the problems seemed to start around 2.6.39. Thought I should note here, my system showed this problem with 2.6.36 through 2.6.39. It seems to have stopped showing the problem (possibly due to a memory upgrade many months ago), but it still has chronic instability of the connection (drops out for varying intervals), and often, network-manager doesn't seem aware of the failure - reloading the driver isn't a reliable solution (sometimes appears to work, often does not) FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
Thought I should note that the addition of "pcie_aspm=off" to my command line has not cured my link problems, but it has changed the behavior of the problems. It is now more likely to recover on its own without me reloading the driver and when I do reload the driver, it is far more likely to "fix" the problem for a while on the first or second try (in the past I often reloaded the driver six or more times to get it working again) It also appears to be far more likely for the link to fail right when I begin using it. This is a strange behavior where if I haven't been doing anything on the web and then attempt to use the web browser, the link fails at that point in time. I leave a one second ping to my server running most of the time and usually have my email program open which maintains an imap connection to the server. When I access the web browser and don't get a response from the web, a quick check shows the ping has stopped receiving responses, but that the email program has not detected a timeout on its link (which I believe takes 15 seconds of down time). The implication is that web access from a relatively inactive state (just the ping and idle imap connection) actually kills the link for some reason. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
Thought I should note that the addition of "pcie_aspm=off" to my command line has not cured my link problems, but it has changed the behavior of the problems. It is now more likely to recover on its own without me reloading the driver and when I do reload the driver, it is far more likely to "fix" the problem for a while on the first or second try (in the past I often reloaded the driver six or more times to get it working again) It also appears to be far more likely for the link to fail right when I begin using it. This is a strange behavior where if I haven't been doing anything on the web and then attempt to use the web browser, the link fails at that point in time. I leave a one second ping to my server running most of the time and usually have my email program open which maintains an imap connection to the server. When I access the web browser and don't get a response from the web, a quick check shows the ping has stopped receiving responses, but that the email program has not detected a timeout on its link (which I believe takes 15 seconds of down time). The implication is that web access from a relatively inactive state (just the ping and idle imap connection) actually kills the link for some reason. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Thu, 1 Mar 2012, Ben Hutchings wrote: On Wed, 2012-02-29 at 21:09 -0800, Shannon Dealy wrote: [...] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. [...] Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. I don't think RAM and PCI cards have ever been on the same bus. And with PCIe there is a separate link to each card. Unfortunately, that doesn't actually isolate them, though it does usually reduce some of the sources of problems. There are always interface chips tying them together (otherwise DMA transfers would not be possible) and the behavior of these chips will change depending on the load and temperature, so activity on the bus on one side of the chip can significantly affect the timing behavior of the chip on the other side (I track down bugs like this for a living, just not on PC's in a very long time). I have seen bugs in software show up due to a change in manufacturing processes used to produce an interface chip in the system and hardware glitches on an "isolated" bus that were due to transmission line effects that rippled right through the chip that was supposed to be isolating the two buses. Of course there is always the old standby of noise passed between chips via the power supply traces. There are many more examples. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Wed, 29 Feb 2012, Juha Jäykkä wrote: that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... I wish they were! They are in X4? and X30? but not X200s, where I had to remove the keyboard and handrest to get to the card. Most annoying. This is why I haven't tried it on my system. Nevertheless, the RAM is quit directly on the opposite side of the motherboard compared to the miniPCI slots (there are two: one is empty, I guess it is meant for 3g), so I would not rule out the miniPCI card moving when addin RAM. Especially since I now have almost 3 days of uptime without problems! This is the record since my problems started except for disabling 802.11n and powersave completely, which gave me about a week. I will report back when I loose wifi again or in two weeks if I do not loose it by then (in which case I will assume it was indeed loose in its socket). You are forgetting that you also added: pcie_aspm=off to your kernel boot command line. Since I did the same thing and have also suddenly enjoyed quite stable WIFI for the first time, I would venture to guess that your problem was not the seating of the card but the "pcie_aspm" option setting. If you want to confirm, you might want to remove that boot option and see if the problem returns. If so, this would be the first really useful confirmation of a specific source for the "deep sleep" problem and provide a workaround for it that others can use, though someone who is familiar with this aspect of the Linux kernel will have to decide what this means in terms of hardware/software issues, what is causing the fault, and how to fix it. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Wed, 29 Feb 2012, Bjørn Mork wrote: Juha Jäykkä writes: One thing just occurred to me: I added 2 GB of memory (total 4 GB) at about the time these problems started. I cannot say for sure the problems did not start earlier, but it is quite possible they started after! (Please do not [snip] This brings up an interesting point, while I have been having assorted other problems, my "deep sleep" issues may have stopped around the time that I upgraded to 8GB of RAM. FWIW I am using the exact same card in an X301 with 8 GB memory and have never seen any such problems. Don't think a RAM upgrade can have any impact, except maybe by causing the card to move in its slot. I assume that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... [snip] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. These changes may be minor, but if the system is running near the limits of the specifications and/or any component on the bus violates the specs, then all sorts of flakey behavior can ensue. Even if everyone plays by the rules, some aspects of bus timings are programmable on some hardware, so a software/firmware bug can also be a source of what would appear to be a "hardware" problems. Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Sun, 26 Feb 2012, Juha Jäykkä wrote: [snip] Shannon: FWIF, I have now rebooted with pci_aspm=off and we'll see what happens. Ben: I also replugged the wifi card. I have also rebooted with pci_aspm=off, and while it has only been a few hours, I have not seen any of the usual irratic behavior that I am used to seeing from the wireless card. Usually this is an ongoing source of irritation to me, though some times it works for a while without problems, so we will see if it lasts. I would have replugged the wifi card a long time ago, but if I recall correctly, it is a little more complicated on this laptop than most I have owned, I don't have the time for it, and am a little wary of tinkering with my main computer when everything I am doing is time critical right now (maybe after I get out of school in a few months). Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Fri, 24 Feb 2012, Juha Jäykkä wrote: [snip] I never had any issues with hibernate or suspend and certainly neither was ever needed to trigger the bug. For example yesterday, I hit the bug after about 3 hours without ever putting the laptop off my lap meanwhile. It wasn't required to trigger the problem on my system either, but it seemed to happen a lot more often in the first few minutes after coming out of hibernation. [snip] What is VERY strange here is the fact that I did not have this problem before going from 2.6.39 to 3.0.0, but not I have it even with 2.6.39! How can that be?!? What else is involved with talking to the wifi card except the kernel and the firmware? Do I need to downgrade iwconfig et al, too? [snip] On my system I could go for weeks without incident, and then have it happen three times in a couple hours. It also appeared to be more prevalent with some versions of the kernel than others (though this may be an illusion due to the irratic nature of the problem). How long did you run it on 2.6.39 previously? Perhaps it would have happened with 2.6.39 previously had you used it for a longer period? Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Sun, 26 Feb 2012, Ben Hutchings wrote: [snip] No, wasn't even aware of its existance. System shows it is currently at "default" unfortunately, the debug kernel I am currently running has the pcie_aspm regression which prevents it from being changed without rebooting which is rather time consuming with my setup. There doesn't seem to be an obvious way to tell what the "default" is. [...] I'm not recommending that you set it. I was concerned that forcing ASPM on could possibly trigger this problem. After looking up the setting, I had assumed that was your concern. However, it seems to me that if it is currently on, then forcing it to "off" might possibly help with the issues with this card. Power management has caused a lot of issues on Linux over the years. Unfortunately, "default" doesn't tell me which state it is actually in. Will give it a try next time I reboot. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Sun, 26 Feb 2012, Ben Hutchings wrote: On Thu, 2012-02-23 at 17:59 -0800, Shannon Dealy wrote: [...] some point, outside software MUST be providing bogus information to the driver. I say this because after the deep sleep bug occcurs and the hardware has been power cycled (through hibernate), the device driver and firmware have been reloaded and right from the start they show the "deep sleep" state again. For a complete power-cycle, you may need to remove both the power cord and the battery. I don't think the Intel wireless cards have any support for wake-on-WAN, but in general devices may still be partly powered as long as any power source is connected to the system. True enough, and I don't remember if I pulled the battery back when I was going after this problem (it has been almost a year since I did all my tests). There is also a switch on the side that kills all RF devices (WLAN and Bluetooth) but I can't verify that it completely kills power to the devices. The log messages you sent are indicative of a total failure of communication with the card. My suspicion would be that the hardware has developed a fault, but it could be as simple as the card being slightly loose in its slot. Hardware failure might make sense except that it has always behaved this way, others have similar symptoms, and most importantly, regardless of what behaviors are occurring (there are a number of problems this card exhibits), while hibernate won't clear the "deep sleep" problem, rebooting the system (without power cycling) clears the problems EVERY time. Whatever the trigger (intermittent hardware fault or driver bug), it appears the kernel is getting into a state from which it is incapable of recovering. Having said that, are you setting the pcie_aspm kernel parameter? No, wasn't even aware of its existance. System shows it is currently at "default" unfortunately, the debug kernel I am currently running has the pcie_aspm regression which prevents it from being changed without rebooting which is rather time consuming with my setup. There doesn't seem to be an obvious way to tell what the "default" is. I should note that I have not seen the "deep sleep" problem in many months, though it is hard to say when or if it has stopped since it often took weeks to show up and my usage patterns have changed considerably. In particular I noticed that hibernate for my system seemed to be a significant contributor to triggering the bug since the problem often showed up in the first few minutes after bringing the computer out of hibernation. This is not a requirement to trigger the problem, just significantly increased the odds. NOTE: I stopped using hibernate in large part because of the "deep sleep" bug. Unfortunately, the other problems of this card continue to plague me (chronic random communication failures being the big one). Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Info received (iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
On Wed, 22 Feb 2012, Juha Jäykkä wrote: Replying to myself, really, but two new observations: There were no problems in the 2.6-series. The bug occurs at least in the Debian kernel versions 3.2.0-1-amd64, 3.0.0-2-amd64, and 3.0.0-1-amd64. As much as I thought and hoped this was true, it is not. I just had the problem with 2.6.39, so... [snip] As my original report noted, I have had the problem in everything from 2.6.36 to 2.6.39 (I also think 2.6.32 but am not certain and didn't have the time to check). I don't recall what I said about firmware, but have tried at least 5 different versions. I have almost completely stopped using hibernate (suspend only) on my system and have not seen the problem in a long time and for my system at least, hibernate seems to be related to the number of incidents of the deep sleep bug. While the firmware may play a role in the problem, at its core, there are issues that must be occurring outside the firmware or even the iwlagn driver, namely a kernel bug or bug in a supporting driver - there is simply no way around this. When a machine has been through a hibernation cycle and completely powered off with the driver unloaded before shutdown, it simply cannot come back up with the "deep sleep" problem still in place unless there is a bug in the kernel or some other driver involved. At some point, outside software MUST be providing bogus information to the driver. I say this because after the deep sleep bug occcurs and the hardware has been power cycled (through hibernate), the device driver and firmware have been reloaded and right from the start they show the "deep sleep" state again. Everything related to the device has been completely reinitialized so they cannot have any "knowledge" of past history or status, so some piece of outside software is holding on to outdated information and not updating. I demonstrated this repeatedly when I first started fighting with the problem. I also have other stability issues with the driver, the most irritating of them is randomly "pausing" for periods of a few seconds up to several minutes where no data gets through, as well as assorted other symptoms consistent with race conditions between the driver and the kernel or other drivers. Again, reloading the driver and/or firmware does not fix these problems, or only does so sporadically. Based on this behavior and the fact that Juha appears to have similar hardware (though not the same model), and my previously noting that many of the people complaining on the internet seemed to be using Lenovo hardware, my recommendation to anyone who has time to investigate would be to look at the Linux driver(s) for the flavor of PCI interface bus these cards plug-in to and the particular chip sets used to implement this bus on the known Lenovo machines having the problem (x201i, x200, ...). My guess is they are using the same hardware and therefore, the same interface driver. I don't know where else the bogus device status information might come from or be stored, but I haven't been keeping up with the Linux kernel for quite a while. Note: my contact at Intel has not responded to my request for status, so I don't know what if anything is happening at their end. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Debian bug #628444
On Sat, 11 Feb 2012, Juha Jäykkä wrote: Hi Shannon! What is the status of the fix from Intel? I have the same problem since upgrading to 3.x series and it is VERY annoying - only way I can fix it is rebooting the kernel, so it really seems a kernel bug. Hibernating the system and doing a full power-off (unplug AC, remove battery, wait 60 seconds – this should do it) the laptop does NOT fix it, so I concur: the kernel must retain some bogus information somewhere since the hw has definitely lost its status info. Hi Juha, Sorry, I haven't heard from him in a couple months. I think both of us are pretty backed up with other things to deal with (as an embedded systems developer, I would have just tracked it down myself if I could spare the time). One thing that seems to have made a difference for me is that I use suspend rather than hibernate these days. This seems to give me much better system stability, particularly with the iwlagn driver, though it shows a number of quirks other than this bug, at least the other ones (so far) can be cured by simply waiting and/or reloading the device driver. I'll send him a message and see what is happening. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
On Wed, 23 Nov 2011, Jonathan Nieder wrote: Shannon Dealy wrote: A developer at Intel contacted me regarding this bug the other day (he was following up on a similar bug report from another source) and I am working with him on the problem (currently doing a debug build of the module to collect data on what is happening). That's good to hear. Did it bear any fruit? (Any test results or public mailing list messages we can look at?) Nothing so far, both he and I are very busy so it is a slow process, waiting for each of us to work the next step into our schedules. Currently I am waiting for his response to a set of data I captured from the driver surrounding one failure. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
A developer at Intel contacted me regarding this bug the other day (he was following up on a similar bug report from another source) and I am working with him on the problem (currently doing a debug build of the module to collect data on what is happening). Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
On Sat, 17 Sep 2011, maximilian attems wrote: I wasn't aware that the 3.0 kernels were out until you sent this message. Unfortunately, since this bug takes time to manifest, it will require that I run with 3.0 as my default kernel, this means I have to get vmware to run with it (since I use it heavily), and that is usually a problem for bleeding edge kernels. I will look into it, but it may be a week or so before I can even try running a 3.0 kernel. bleeding edge would be against linux-next, 3.1-rcX is in experimental. that would be next target if problem persists. Bleeding edge is anything which hasn't been in use long enough that there is still significant potential for major bugs. Having had very long experience with the Linux kernel (and having fixed the bugs myself on several occasions), the 3.x kernels qualify. Anyway according to your description you are loading binary blobs into your OS, so you just voided our support and this bug report can be closed away unless you can reproduce without. 1- Actually, VMWare provides the source code for their kernel interface code which uses loadable modules, but usually someone has to work up a source code patch for the latest versions of the kernel (< 6-9 months old) and then users have to patch and rebuild the kernel interface. I have worked up patches myself on a few occasions, but I don't really have the time. 2- I wasn't running VMWare at the time I reported these problems, I use it only for customer software development and there weren't any customers back then. Now I am rather busy. So no, this bug report cannot be closed on that basis and as I stated before, even a cursory scan of the internet shows this is a common problem for people running similar hardware, so even if I were running "binary blobs", the bug should remain open. NOTE: If one were to assume that VMWare were in any way relevant to this problem, then the bug should move from machine to machine as I migrate my development environment. Instead, the bug showed up when I moved to a new machine with different hardware and device drivers, but the same kernel. I upgraded to a variety of different kernels in the hope that one of them would work and have settled on the current one I am running because it seems to have the problem less often. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#641845: upowerd: upowerd wastes power by writing to disk too often
Package: upower Version: 0.9.5-5 Severity: normal File: upowerd I was surprized to find that the reason my laptop disk keeps spinning up is the "upowerd" power management daemon. It is writing to its history files at least a couple times a minute. It seems to me that any program involved in power management should be more careful in its use of power. Ideally, it would only push its data to disk when the disk is already spun up, possibly with a maximum time limit of 20 minutes or when some maximum amount of buffered data is reached, whichever comes first. Alternatively, it should allow for at least several minutes of data to buffer before flushing to disk. Even better would be if whichever of the above is implemented were configurable (buffer size and time limit) in a run-time configuration file or as a command line option. -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 2.6.36-trunk-686-bigmem (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages upower depends on: ii dbus 1.2.24-4+squeeze1 simple interprocess messaging syst ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgudev-1.0-0 164-3 GObject-based wrapper library for ii libimobiledevice1 1.0.2-1 Library for communicating with the ii libplist1 1.3-2 Library for handling Apple binary ii libpolkit-gobject-1-0 0.96-4PolicyKit Authorization API ii libupower-glib10.9.5-5 abstraction for power management - ii libusb-1.0-0 2:1.0.8-2 userspace USB programming library ii udev 164-3 /dev/ and hotplug management daemo Versions of packages upower recommends: ii pm-utils 1.3.0-3utilities and scripts for power ma ii policykit-1 0.96-4 framework for managing administrat upower suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
On Tue, 13 Sep 2011, maximilian attems wrote: tags 628444 moreinfo stop This bug actually applies to all Debian kernels I have tried including 2.6.36, 2.6.37, 2.6.38, and 2.6,39 Did you try since newer 3.0 images, how are they performing? thank you I wasn't aware that the 3.0 kernels were out until you sent this message. Unfortunately, since this bug takes time to manifest, it will require that I run with 3.0 as my default kernel, this means I have to get vmware to run with it (since I use it heavily), and that is usually a problem for bleeding edge kernels. I will look into it, but it may be a week or so before I can even try running a 3.0 kernel. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637009: xdrawchem: Wrong path to "help" from molecule info window
Package: xdrawchem Version: 1.9.9-4.1 Severity: normal If you click the "help" button from the "molecule info" window, it attempts to display the file: /usr/share/xdrawchem/doc/molinfo.html which results in a blank display. The above path is incorrect and should instead be: /usr/share/doc/xdrawchem/html/molinfo.html which is where the file is currently located. -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: i386 (i686) Kernel: Linux 2.6.36-trunk-686-bigmem (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xdrawchem depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-8 GCC support library ii libopenbabel3 2.2.3-1+b1Chemical toolbox library ii libqt3-mt 3:3.3.8b-7+b1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 xdrawchem recommends no packages. xdrawchem suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607673: GTK_IM_MODULE setting
Was changing window managers and discovered that the problem with gnucash and the scim daemon on my system is specific to the setting of GTK_IM_MODULE. If it is set to "xim" gnucash editing is broken (arrows, delete/backspace), if it is set to "scim" then it appears to work fine. My understanding is that scim is supposed to be able to work with xim (and it apparently does for my other apps), though I don't recall why I set it up this way years ago as it does not appear to be necessary for my current usage. In any case, switching so: GTK_IM_MODULE="scim" appears to solve my problem, though the bug is still there, this appears to make it a non-issue for me. Perhaps this may give some clues to make it easier to track down the problem. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: Acknowledgement (linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation)
Oops, the previously closed bug I mentioned should have been: #589353 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589353 NOT #589383 Sorry for the confusion. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation
Package: linux-2.6 Version: 2.6.39-1 Severity: important After some arbitrary period of use, wifi fails and errors show up in syslog indicating "MAC is in deep sleep" after which nothing can be done to restore wifi functionality other than rebooting the system. In most (possibly all) cases, the failure occurs after the laptop has been suspended and resumed at least once, though the actual occurance may not be immediately after resuming, it often occurs within a few minutes after resume. Unloading and reloading the iwlagn driver and the drivers it relies on have no effect. Speculation: there is a mechanical switch on the side of the laptop which cuts power to both bluetooth and wifi on this machine. Unloading iwlagn turning off the switch waiting ten seconds, then turning it on and reloading iwlagn also has no effect. Assuming this switch actually is a hardware power off of the devices, this should reset the device and a reload of the driver should restore functionality. Since this does not occur, I see only two possibilities, either the "power switch" does not completely power off the device, or the kernel is retaining some bogus information (possibly placed there by iwlagn) about the device in spite of the driver being unloaded and reloaded. Even if it doesn't prevent the problem, simply curing this issue so the device can be restarted without rebooting would be a major improvement. I have tried a number of different versions of the firmware as well as different kernels, all combinations have the problem, though some seem to be more stable than others. In some combinations it make take one to two weeks of usage with perhaps a dozen suspend resume cycles per day, in others it seems to happen every day. I have noted in my search of the net that Lenovo laptops seem to be most (possibly all, I wasn't paying close attention) of the cases where this bug occurs. My system is a Lenovo x201i, the wifi adapter was listed as an: "Intel Centrino Advanced-N 6200 (2x2 AGN)" This bug actually applies to all Debian kernels I have tried including 2.6.36, 2.6.37, 2.6.38, and 2.6,39 (various versions of each and I think it included earlier ones, but I don't remember which ones and no longer have them installed). NOTE: this appears to be the same as closed bug 589383 which was closed upstream and tagged "unreproducible". Even the most cursory search of the net shows there are lots of people having no problems reproducing it. It strikes me as inappropriate to close a bug as unreproducible when it is quite clear that many people are seeing it. May 28 15:19:12 nashapur kernel: [16275.165421] iwlagn :02:00.0: Error sending REPLY_ADD_STA: time out after 500ms. May 28 15:19:12 nashapur kernel: [16275.165428] HW problem - can not stop rx aggregation for tid 0 May 28 15:19:12 nashapur ifd[1923]: executing: '/usr/share/laptop-net/link-change wlan0 unmanaged up,running,connected up,running,disconnected' May 28 15:19:12 nashapur kernel: [16275.664639] iwlagn :02:00.0: Error sending REPLY_QOS_PARAM: time out after 500ms. May 28 15:19:12 nashapur kernel: [16275.664644] iwlagn :02:00.0: Failed to update QoS May 28 15:19:12 nashapur kernel: [16275.748419] iwlagn :02:00.0: Queue 2 stuck for 2000 ms. May 28 15:19:12 nashapur kernel: [16275.748429] iwlagn :02:00.0: On demand firmware reload May 28 15:19:13 nashapur kernel: [16276.163702] iwlagn :02:00.0: Error sending REPLY_RXON: time out after 500ms. May 28 15:19:13 nashapur kernel: [16276.163709] iwlagn :02:00.0: Error clearing ASSOC_MSK on BSS (-110) May 28 15:19:13 nashapur kernel: [16276.180377] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.196983] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.213584] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.230200] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.246801] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.263411] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.280011] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.296612] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.313214] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.329830] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.346433] iwlagn :02:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x May 28 15:19:13 nashapur kernel: [16276.363037]
Bug#607673: gnucash: Left arrow, right arrow and backspace keys don't work in register
On Mon, 24 Jan 2011, Micha Lenk wrote: Hi Shannon, You wrote: So the problem would appear to be SCIM related, but (not knowing the [snip] Gnucash 2.4.0 is now available in experimental. This new upstream version can be considered rather stable, but was not uploaded to experimental due to the freeze for Debian Squeeze. Would you mind to install the package from experimental and try-out whether your problem persists? Hi Micha, No change. Installed gnucash from experimental and still can't edit the register (left/right arrows and backspace key) as long as SCIM is running (even though it is not active). Terminate the SCIM daemon and immediately register editing works correctly, restart the daemon and editing is broken again. This worked fine in Lenny, just not in squeeze or the current experimental. So far I have not seen this problem with any other program, so it still appears that gnucash is the problem Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607673: gnucash: Left arrow, right arrow and backspace keys don't work in register
Hi Micha, Your idea that it was SCIM related was correct, however, it wasn't the patch that is the problem. I tried rebuilding and installing gnucash as you suggested without the "10_fix_broken_SCIM_input_bug_587298" patch and it had no effect. However, I do run with SCIM installed (for use with other programs), and terminating it allowed both versions of gnucash to start working correctly (with and without the above patch). Restart the background daemon and gnucash immediately stops working correctly. So the problem would appear to be SCIM related, but (not knowing the internals of gnucash), I do find it puzzling that the problem only affects transaction editing (register and scheduled transactions), but not any other dialogs that I have tried. I would have expected that all keyboard input to the program would behave the same. Regards, Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607673: gnucash: Left arrow, right arrow and backspace keys don't work in register
Package: gnucash Version: 2.2.9-10 Severity: important I just upgraded my system to squeeze and in gnucash I am no longer able to use the left-arrow, right-arrow, or backspace keys to edit transactions or register entries. Other keys that I don't normally use for editing may be broken as well. Up-arrow and down-arrow keys work as expected for scrolling through the register. These keys all work in every dialog box of gnucash that I have tried and all other applications that I am using, just the main register and the scheduled transaction editor windows where checks and other transactions are entered or modified has the problem of them being non-functional. This is a major problem for data entry as the only way I have found to correct an error is to delete the transaction and re-enter it from scratch. As I found it hard to believe that a problem like this would not have been noticed already by others, I have tried: starting the program after deleting my .gnucash directory purging/reinstalling gnucash (which caused about 20 other packages to also be removed/reinstalled) rebooting the system assuming that it might be caused by some form of local corruption of my system, none of these had any effect. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.36-trunk-686-bigmem (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnucash depends on: ii gconf2 2.28.1-6 GNOME configuration database syste ii gnucash-common 2.2.9-10 A personal finance and money track ii guile-1.6-libs 1.6.8-10 Main Guile libraries ii guile-1.6-slib 1.6.8-10 Guile SLIB support ii libaqbanking29 4.2.4-2 library for online banking applica ii libart-2.0-22.3.21-1 Library of functions for 2D graphi ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libbonobo2-02.24.3-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.24.3-1 The Bonobo UI library ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcrypt-ssleay-perl0.57-2 Support for https protocol in LWP ii libdate-manip-perl 6.11-1 module for manipulating dates ii libenchant1c2a 1.6.0-1 a wrapper library for various spel ii libfinance-quote-perl 1.17-1 Perl module for retrieving stock q ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgnome2-0 2.30.0-1 The GNOME library - runtime files ii libgnomecanvas2-0 2.30.1-1 A powerful object-oriented display ii libgnomeui-02.24.3-1 The GNOME libraries (User Interfac ii libgnomevfs2-0 1:2.24.3-1 GNOME Virtual File System (runtime ii libgoffice-0.8-80.8.12-1 Document centric objects library - ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libgtkhtml3.14-19 3.30.3-1 HTML rendering/editing library - r ii libguile-ltdl-1 1.6.8-10 Guile's patched version of libtool ii libgwenhywfar47 3.11.3-1 OS abstraction layer ii libice6 2:1.0.6-2X11 Inter-Client Exchange library ii libktoblzcheck1c2a 1.28-1 library for verification of accoun ii libltdl72.2.6b-2 A system independent dlopen wrappe ii libofx4 1:0.9.0-3library to support Open Financial ii liborbit2 1:2.14.18-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libpopt01.16-1 lib for parsing cmdline parameters ii libqthreads-12 1.6.8-10 QuickThreads library for Guile ii libsm6 2:1.1.1-1X11 Session Management library ii libx11-62:1.3.3-4X11 client-side library ii libxml2 2.7.8.dfsg-1 GNOME XML library ii slib3b1-3.1 Portable Scheme library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnucash recommends: ii gnucash-docs 2.2.0-3Documentation for gnucash, a perso gnucash suggests no packages. -- no debconf information
Bug#603770: flashplugin-nonfree: Out of date checksum again
Package: flashplugin-nonfree Version: 1:2.8.2 Severity: grave Justification: renders package unusable Adobe has again updated their flash player version 10 (now dated Nov. 11, 2010) Attempting to install gives the following error: ERROR: sha512sum rejected install_flash_player_10_linux.tar.gz More information might be available at: http://wiki.debian.org/FlashPlayer For this package to be usable for any period of time, it needs to not use a fixed built-in checksum (which I assume is the source of the error). Otherwise, it could be broken again by Adobe doing a new release the day after this is fixed, or the day of the next Debian release for that matter. Possibly it could give a warning on checksum error and allow the user to decide whether or not to install rather than failing outright. I realize there are potential problems with this approach too, but the current approach is badly broken and this might make it less of a problem. FWIW. -- Package-specific info: Debian version: squeeze/sid Architecture: i386 Package version: 1:2.8.2 MD5 checksums: md5sum: /var/cache/flashplugin-nonfree/*: No such file or directory md5sum: /usr/lib/flashplugin-nonfree/libflashplayer.so: No such file or directory Alternatives: update-alternatives: error: no alternatives for flash-mozilla.so. ls: cannot access /usr/lib/mozilla/plugins/flash-mozilla.so: No such file or directory /usr/lib/mozilla/plugins/flash-mozilla.so: ERROR: cannot open `/usr/lib/mozilla/plugins/flash-mozilla.so' (No such file or directory) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages flashplugin-nonfree depends on: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-1FreeType 2 font engine, shared lib ii libgcc1 1:4.4.5-6 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libnspr4-0d 4.8.6-1NetScape Portable Runtime Library ii libnss3-1d3.12.8-1 Network Security Service libraries ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libstdc++64.4.5-6The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-3 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii wget 1.12-2.1 retrieves files from the web flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: pn flashplugin-nonfree-extrasoun (no description available) ii iceweasel 3.5.15-1 Web browser based on Firefox pn konqueror-nsplugins(no description available) ii msttcorefonts 2.7transitional dummy package ii ttf-dejavu2.31-1 Metapackage to pull in ttf-dejavu- ii ttf-mscorefonts-installer [ms 3.3Installer for Microsoft TrueType c pn ttf-xfree86-nonfree(no description available) ii x-ttcidfont-conf 32 TrueType and CID fonts configurati -- debconf information: flashplugin-nonfree/httpget: false flashplugin-nonfree/not_exist: flashplugin-nonfree/local: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592434: xserver-xorg-core: Broken GLX causes flash to crash when switching to full screen
On Wed, 11 Aug 2010, Michel Dänzer wrote: On Mon, 2010-08-09 at 19:39 -0700, Shannon Dealy wrote: (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="FireGL - ATI Technologies Inc." compiled for 7.5.0, module version = 1.0.0 (II) Loading extension GLX Looks like your /usr/lib/xorg/modules/extensions/libglx.so is from an fglrx driver installation, which probably can't work with other drivers. Try fixing that. Not sure how that ended up installed on the system, but the dist-upgrade to testing was not clean/easy and dependency chaos reigned for a while. While removing the fglrx packages now allows glx to run without crashing flash in full screen mode (thanks), this still leaves the issue of why is X not aborting on what should in my view be a fatal error at startup? Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#592434: xserver-xorg-core: Broken GLX causes flash to crash when switching to full screen
Package: xserver-xorg-core Version: 2:1.7.7-3 Severity: important When using flash under firefox or chromium, switching it to full screen mode causes flash to segfault. I just upgraded this computer to testing, however, both the adobe flash plugin and chromium were already running the latest versions so they were not upgraded. Both were working fine before the upgrade. I found the following error in the Xorg log file: (EE) GLX error: Can not get required symbols. Searching the net I found reference to this error with a different X driver having a possible fix by setting in the monitor section: option "DPMS" "true" this had no effect. Finally in the Module section of xorg.conf I changed: Load "glx" to Disable "glx" which resolved the immediate problem, except of course that glx is still broken. As I see it, there are a few issues here which should be resolved: 1 - The cause of the "(EE) GLX error: Can not get required symbols." error needs to be fixed. 2 - X should abort when an error like this occurs rather than continuing to run with what is apparently a corrupt environment. 3 - If X is going to continue to run after an error like this, it needs to cleanly remove the offending module. This clearly did not happen, otherwise, there would be no difference between running flash with glx failing to load correctly and glx disabled. As a copy of the full log file is included below from the successful run, I am including here the diffs between the log files from successful and failed sessions: 16c16 < (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 9 19:29:07 2010 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 9 19:13:23 2010 57c57 < (++) using VT number 9 --- > (++) using VT number 8 62d61 < (WW) "glx" will not be loaded unless you've specified it to be loaded elsewhere. 65c64 < (II) "glx" will be loaded even though the default is to disable it. --- > (II) "glx" will be loaded. This was enabled by default and also specified in > the config file. 85a85,89 > (II) LoadModule: "glx" > (II) Loading /usr/lib/xorg/modules/extensions/libglx.so > (II) Module glx: vendor="FireGL - ATI Technologies Inc." > compiled for 7.5.0, module version = 1.0.0 > (II) Loading extension GLX 335a340 > (EE) GLX error: Can not get required symbols. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Oct 16 2006 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1725304 Jul 15 09:15 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 2586 Aug 9 18:09 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf.dpkg-new (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf.dpkg-new manual page. # (Type "man xorg.conf.dpkg-new" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf.dpkg-new /etc/X11/xorg.conf.dpkg-new.custom # md5sum /etc/X11/xorg.conf.dpkg-new >/var/lib/xfree86/xorg.conf.dpkg-new.md5sum # dpkg-reconfigure xserver-xorg Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/share/fonts/X11/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"i2c" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Disable "glx" # Load"glx" Load"extmod" Load"freetype" Load"int10" Load"record" Load"v4l" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse"
Bug#537968: gnome-mount: Doesn't auto mount partitions greater than 1 TB in size
Package: gnome-mount Version: 0.7-2 Severity: normal I have a 1.5 terabyte USB hard drive, if I partition it with less than one terabyte of data in a partion, it is automatically mounted when I plug it into the computer, if I cross the one terabyte boundary with the partition size, it won't automatically mount (though I can mount it manually without problems). I tried this with both an ext3 file system and an encrypted setup (my original config) which prompts for the pass phrase only if the partition is less than one terabyte, otherwise there is no prompt and nothing is mounted. I haven't found anything that looks like an error message relating to this, but I am a little fuzzy on the exact chain of events between HAL and gnome-mount, so I may not be looking in the right place. cfdisk partitioning: This works: size entered: 1099510 MB, actual size displayed: 1099506.08 MB This fails (as does any larger value): size entered: 1099511 MB, actual size displayed: 1099514.31 MB the exact power of 2 definition of "one terabyte" falls between the above two values, so I assume it is in some way significant. syslog output after connecting the drive: Jul 21 18:19:00 nashapur kernel: [19786.993063] usb 1-2: new high speed USB device using ehci_hcd and address 13 Jul 21 18:19:00 nashapur kernel: [19787.142662] usb 1-2: New USB device found, idVendor=0bc2, idProduct=3001 Jul 21 18:19:00 nashapur kernel: [19787.142672] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jul 21 18:19:00 nashapur kernel: [19787.142680] usb 1-2: Product: FreeAgent Jul 21 18:19:00 nashapur kernel: [19787.142685] usb 1-2: Manufacturer: Seagate Jul 21 18:19:00 nashapur kernel: [19787.142690] usb 1-2: SerialNumber: 2GEV3WR1 Jul 21 18:19:00 nashapur kernel: [19787.142939] usb 1-2: configuration #1 chosen from 1 choice Jul 21 18:19:00 nashapur kernel: [19787.180655] scsi10 : SCSI emulation for USB Mass Storage devices Jul 21 18:19:00 nashapur NetworkManager: [1248225540.458861] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1'). Jul 21 18:19:00 nashapur kernel: [19787.248678] usb-storage: device found at 13 Jul 21 18:19:00 nashapur kernel: [19787.248685] usb-storage: waiting for device to settle before scanning Jul 21 18:19:00 nashapur chipcardd[4492]: devicemanager.c: 3373: Changes in hardware list Jul 21 18:19:00 nashapur NetworkManager: [1248225540.664732] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1_usbraw'). Jul 21 18:19:00 nashapur NetworkManager: [1248225540.948645] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1_if0'). Jul 21 18:19:00 nashapur NetworkManager: [1248225540.969204] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1_if0_scsi_host'). Jul 21 18:19:05 nashapur kernel: [19792.253791] usb-storage: device scan complete Jul 21 18:19:05 nashapur kernel: [19792.255346] scsi 10:0:0:0: Direct-Access Seagate FreeAgent102C PQ: 0 ANSI: 4 Jul 21 18:19:05 nashapur NetworkManager: [1248225545.755447] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1_if0_scsi_host_0'). Jul 21 18:19:05 nashapur NetworkManager: [1248225545.763170] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_bc2_3001_2GEV3WR1_if0_scsi_host_0_scsi_device_lun0'). Jul 21 18:19:16 nashapur kernel: [19802.994361] sd 10:0:0:0: [sdb] 2930277168 512-byte hardware sectors: (1.50 TB/1.36 TiB) Jul 21 18:19:16 nashapur kernel: [19802.995706] sd 10:0:0:0: [sdb] Write Protect is off Jul 21 18:19:16 nashapur kernel: [19802.995719] sd 10:0:0:0: [sdb] Mode Sense: 1c 00 00 00 Jul 21 18:19:16 nashapur kernel: [19802.995728] sd 10:0:0:0: [sdb] Assuming drive cache: write through Jul 21 18:19:16 nashapur kernel: [19802.997822] sd 10:0:0:0: [sdb] 2930277168 512-byte hardware sectors: (1.50 TB/1.36 TiB) Jul 21 18:19:16 nashapur kernel: [19802.999168] sd 10:0:0:0: [sdb] Write Protect is off Jul 21 18:19:16 nashapur kernel: [19802.999177] sd 10:0:0:0: [sdb] Mode Sense: 1c 00 00 00 Jul 21 18:19:16 nashapur kernel: [19802.999183] sd 10:0:0:0: [sdb] Assuming drive cache: write through Jul 21 18:19:16 nashapur kernel: [19802.999195] sdb: sdb1 Jul 21 18:19:16 nashapur kernel: [19803.008167] sd 10:0:0:0: [sdb] Attached SCSI disk Jul 21 18:19:16 nashapur NetworkManager: [1248225556.995099] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/storage_serial_Seagate_FreeAgent_2GEV3WR1_0_0'). Jul 21 18:19:21 nashapur kernel: [19808.353084] ===>rt_ioctl_giwscan. 1(1) BSS returned, data->length = 83 Jul 21 18:19:26 nashapur kernel: [19813.340151] ===>rt_ioctl_giwscan. 1(1) BSS returned, data->length = 83 -- System Informatio
Bug#355637: mailman: Stale lock files break administrative web interface
Package: mailman Version: 2.1.5-7 Severity: normal Under some circumstances (presumably mailman software or system crashes), list specific stale lock files are left in the directory /var/lib/mailman/locks this can permanently prevent administrative login for that specific list until the lock file(s) are removed. It also seems to result in irratic behavior for some other aspects of the list software (heavy cpu loading, refusal of qrunner process to cleanly shutdown requiring a hard kill). There appears to be no mechanism to cleanup these stale lock files (there were a couple in the directory dating back several years), and restarting mailman or even rebooting the system does not clean things up. At the very least restarting mailman should cleanup these stale lock files, in particular what I assume is the master lock: listname.lock and probably the actual source of my problems. A better solution would probably include actually checking the lock files periodically to make sure they are still valid. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11.10-bs5deatech Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mailman depends on: ii apache [httpd]1.3.33-6sarge1 versatile, high-performance HTTP s ii apache2-mpm-prefork [http 2.0.54-5 traditional model for Apache2 ii cron 3.0pl1-86 management of regular background p ii debconf 1.4.30.13 Debian configuration management sy ii exim [mail-transport-agen 3.36-16An MTA (Mail Transport Agent) ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii logrotate 3.7-5 Log rotation utility ii pwgen 2.03-1 Automatic Password generation ii python2.3.5-2An interactive high-level object-o ii ucf 1.17 Update Configuration File: preserv -- debconf information: * mailman/queue_files_present: mailman/default_server_language: en * mailman/gate_news: false * mailman/site_languages: en * mailman/used_languages: en * mailman/create_site_list: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304538: Still broken: 248622 - exim_tidydb failed to open DB file
Package: exim Version: 3.36-14 Severity: normal The bug previously reported in #248622 (caused by incompatible database formats), and closed by this version of exim (3.36-14) still exists in this version. Among the changes noted in the message closing the previous bug report was that the postinst script was calling db3_upgrade to fix this problem, however, if it is doing so, it doesn't do it directly and I was unable to locate any indirect calls to db3_upgrade either. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.27-2-586tsc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages exim depends on: ii cron3.0pl1-86management of regular background p ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libdb3 3.2.9-22 Berkeley v3 Database Libraries [ru ii libident0.22-3 simple RFC1413 client library - ru ii libldap22.1.30-3 OpenLDAP libraries ii libpam0g0.76-22 Pluggable Authentication Modules l ii libpcre34.5-1.1 Perl 5 Compatible Regular Expressi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
