From post at volker-wysk.de Wed Nov 1 16:02:47 2017 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 01 Nov 2017 21:02:47 +0100 Subject: [moin-user] MoinMoin very slow Message-ID: <10942129.O9o76ZdvQC@desktop> Hello! My MoinMoin has become very slow. It takes some 30 seconds to save a (long) page. It's just one user (me). It doesn't make a difference if i'ts the text editor or the GUI. Any hints? Volker From paul at boddie.org.uk Wed Nov 1 16:49:49 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 1 Nov 2017 21:49:49 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <10942129.O9o76ZdvQC@desktop> References: <10942129.O9o76ZdvQC@desktop> Message-ID: <201711012149.49335.paul@boddie.org.uk> On Wednesday 1. November 2017 21.02.47 Volker Wysk wrote: > > My MoinMoin has become very slow. It takes some 30 seconds to save a (long) > page. > > It's just one user (me). > > It doesn't make a difference if i'ts the text editor or the GUI. > > Any hints? The show_timings setting might provide some more detail about where Moin is spending its time: https://moinmo.in/HelpOnConfiguration#style Other than that, some kind of idea of the environment Moin is operating in might be useful... Publicly accessible or inaccessible? Lots of processes on the machine or only a few? Local or network filesystem? Nameserver usage: are the Web server and Moin doing reverse DNS lookups? Try show_timings first of all, though. Paul From post at volker-wysk.de Wed Nov 1 18:44:28 2017 From: post at volker-wysk.de (Volker Wysk) Date: Wed, 01 Nov 2017 23:44:28 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711012149.49335.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <201711012149.49335.paul@boddie.org.uk> Message-ID: <2111587.7j9o1Vg0Pa@desktop> Am Mittwoch, 1. November 2017, 21:49:49 CET schrieb Paul Boddie: > On Wednesday 1. November 2017 21.02.47 Volker Wysk wrote: > > > > My MoinMoin has become very slow. It takes some 30 seconds to save a (long) > > page. > > > > It's just one user (me). > > > > It doesn't make a difference if i'ts the text editor or the GUI. > > > > Any hints? > > The show_timings setting might provide some more detail about where Moin is > spending its time: > > https://moinmo.in/HelpOnConfiguration#style This looks like this: Page.execute = 20.668s i18n_init = 0.299s init = 0.370s loadLanguage = 0.115s load_multi_cfg = 0.274s run = 41.985s send_page = 41.809s send_page_content = 41.156s send_page_content|1 = 20.578s send_page|1 = 20.578s total = 42.354s > Other than that, some kind of idea of the environment Moin is operating in > might be useful... Kubuntu 16.04, Apache2, ... > Publicly accessible or inaccessible? inaccessible, one user only > Lots of processes on the machine or only a few? This process runs alle the time with 100% CPU: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python > Local or network filesystem? Local. > Nameserver usage: are the Web server and Moin doing reverse DNS lookups? How to find this out? > Try show_timings first of all, though. See above. And: It runs much faster for smaller pages. Thnx Volker From paul at boddie.org.uk Wed Nov 1 19:16:05 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 00:16:05 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <2111587.7j9o1Vg0Pa@desktop> References: <10942129.O9o76ZdvQC@desktop> <201711012149.49335.paul@boddie.org.uk> <2111587.7j9o1Vg0Pa@desktop> Message-ID: <201711020016.06672.paul@boddie.org.uk> On Wednesday 1. November 2017 23.44.28 Volker Wysk wrote: > > This looks like this: > > Page.execute = 20.668s > i18n_init = 0.299s > init = 0.370s > loadLanguage = 0.115s > load_multi_cfg = 0.274s > run = 41.985s > send_page = 41.809s > send_page_content = 41.156s > send_page_content|1 = 20.578s > send_page|1 = 20.578s > total = 42.354s So, working through this without any recent knowledge or experience myself, I see that the MoinMoin.Page.Page.send_page_content method is the thing using all the time. It obtains a parser and then either gets a cached version of the page or formats a new version. Is there anything special about the page? Anything like macros being used, for instance. > > Other than that, some kind of idea of the environment Moin is operating > > in might be useful... > > Kubuntu 16.04, Apache2, ... > > > Publicly accessible or inaccessible? > > inaccessible, one user only > > > Lots of processes on the machine or only a few? > > This process runs alle the time with 100% CPU: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python This indicates that it is presumably quite busy and not necessarily waiting for input/output, so the nameserver suggestion is probably uninteresting. > > Local or network filesystem? > > Local. > > > Nameserver usage: are the Web server and Moin doing reverse DNS lookups? > > How to find this out? I suppose the easiest way is to just look at your Apache and Moin logs and see if you have numeric IP addresses or ones with actual names. But I doubt that this would cause the time to be consumed in send_page_content, so we can perhaps rule this out as a cause. > > Try show_timings first of all, though. > > See above. > > And: It runs much faster for smaller pages. I do wonder about "send_page_content|1" which might well be a recursive call generating a subpage, perhaps for a table of contents. The way that the combined time is approximately double the individual times might suggest that the cache isn't working properly. But 20s page generation times are not exactly normal, either. It's been a long time since I troubleshooted a Moin performance problem like this, and then I think it was probably related to the low-performance, non- Xapian search function, not page loading. Paul From post at volker-wysk.de Thu Nov 2 03:29:13 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 08:29:13 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711020016.06672.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <2111587.7j9o1Vg0Pa@desktop> <201711020016.06672.paul@boddie.org.uk> Message-ID: <2046011.4oLZGMOQcC@desktop> Am Donnerstag, 2. November 2017, 00:16:05 CET schrieb Paul Boddie: > On Wednesday 1. November 2017 23.44.28 Volker Wysk wrote: > > > > This looks like this: > > > > Page.execute = 20.668s > > i18n_init = 0.299s > > init = 0.370s > > loadLanguage = 0.115s > > load_multi_cfg = 0.274s > > run = 41.985s > > send_page = 41.809s > > send_page_content = 41.156s > > send_page_content|1 = 20.578s > > send_page|1 = 20.578s > > total = 42.354s > > So, working through this without any recent knowledge or experience myself, I > see that the MoinMoin.Page.Page.send_page_content method is the thing using > all the time. It obtains a parser and then either gets a cached version of the > page or formats a new version. > > Is there anything special about the page? Anything like macros being used, for > instance. I'm using some <
> macros, and a "#!highlight" parser. Also using <>. Disabling the TOC and the parser didn't speed things up. > > > Other than that, some kind of idea of the environment Moin is operating > > > in might be useful... > > > > Kubuntu 16.04, Apache2, ... > > > > > Publicly accessible or inaccessible? > > > > inaccessible, one user only > > > > > Lots of processes on the machine or only a few? > > > > This process runs alle the time with 100% CPU: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python > > This indicates that it is presumably quite busy and not necessarily waiting > for input/output, so the nameserver suggestion is probably uninteresting. I've tried vwysk.now-dns.net (my dynamic DNS-Name), localhost and 127.0.0.1. No luck. All slow. > > > > Local or network filesystem? > > > > Local. > > > > > Nameserver usage: are the Web server and Moin doing reverse DNS lookups? > > > > How to find this out? > > I suppose the easiest way is to just look at your Apache and Moin logs and see > if you have numeric IP addresses or ones with actual names. But I doubt that > this would cause the time to be consumed in send_page_content, so we can > perhaps rule this out as a cause. > > > > Try show_timings first of all, though. > > > > See above. > > > > And: It runs much faster for smaller pages. > > I do wonder about "send_page_content|1" which might well be a recursive call > generating a subpage, perhaps for a table of contents. The way that the > combined time is approximately double the individual times might suggest that > the cache isn't working properly. But 20s page generation times are not > exactly normal, either. A special cache for MoinMoin? How do you configure it? I might not have installed it, because I thought I don't need it. > It's been a long time since I troubleshooted a Moin performance problem like > this, and then I think it was probably related to the low-performance, non- > Xapian search function, not page loading. Regards, Volker From paul at boddie.org.uk Thu Nov 2 08:11:36 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 13:11:36 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <2046011.4oLZGMOQcC@desktop> References: <10942129.O9o76ZdvQC@desktop> <201711020016.06672.paul@boddie.org.uk> <2046011.4oLZGMOQcC@desktop> Message-ID: <201711021311.38509.paul@boddie.org.uk> On Thursday 2. November 2017 08.29.13 Volker Wysk wrote: > Am Donnerstag, 2. November 2017, 00:16:05 CET schrieb Paul Boddie: > > > > Is there anything special about the page? Anything like macros being > > used, for instance. > > I'm using some <
> macros, and a "#!highlight" parser. Also using > <>. Disabling the TOC and the parser didn't speed things > up. OK. From what I can gather, I guess that the highlight parser wouldn't affect performance that much anyway. [...] > > I do wonder about "send_page_content|1" which might well be a recursive > > call generating a subpage, perhaps for a table of contents. The way that > > the combined time is approximately double the individual times might > > suggest that the cache isn't working properly. But 20s page generation > > times are not exactly normal, either. > > A special cache for MoinMoin? How do you configure it? I might not have > installed it, because I thought I don't need it. No, the cache is built into MoinMoin, so it should just work. However, it seems to be a constant source of problems, usually producing errors that are often dealt with using "moin maint cleancache". I imagine that we might need to dig deeper to see where Moin is spending all its time. Did you look at the following page, by the way...? https://moinmo.in/HowTo/Tune%20Performance Paul From post at volker-wysk.de Thu Nov 2 09:28:17 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 14:28:17 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021311.38509.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <2046011.4oLZGMOQcC@desktop> <201711021311.38509.paul@boddie.org.uk> Message-ID: <7403384.JQaWJBRKkV@desktop> Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie: > However, it > seems to be a constant source of problems, usually producing errors that are > often dealt with using "moin maint cleancache". This produces an error: desktop ~ % moin maint cleancache 2017-11-02 13:54:01,964 INFO MoinMoin.log:151 using logging configuration read from built-in fallback in MoinMoin.log module 2017-11-02 13:54:01,964 INFO MoinMoin.log:157 Running MoinMoin 1.9.9 release code from /usr/local/lib/python2.7/dist-packages/MoinMoin 2017-11-02 13:54:02,361 ERROR MoinMoin.config.multiconfig:129 Could not import. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/MoinMoin/config/multiconfig.py", line 123, in _makeConfig module, mtime = _importConfigModule(name) File "/usr/local/lib/python2.7/dist-packages/MoinMoin/config/multiconfig.py", line 48, in _importConfigModule module = __import__(name, globals(), {}) ImportError: No module named wikiconfig Traceback (most recent call last): (...) I'm configuring everything in /usr/local/share/moin/config/wikiconfig.py. What is this "multiconfig.py" thing ...? I don't have it. Chees Volker From post at volker-wysk.de Thu Nov 2 10:58:04 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 15:58:04 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021311.38509.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <2046011.4oLZGMOQcC@desktop> <201711021311.38509.paul@boddie.org.uk> Message-ID: <2783415.eSmmzF7rRR@desktop> Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie: > I imagine that we might need to dig deeper to see where Moin is spending all > its time. Did you look at the following page, by the way...? > > https://moinmo.in/HowTo/Tune%20Performance Now I have. Can it because of using CGI instead of WSGI? I've also tried "log_reverse_dns_lookups = False", but it's still slow. Volker From paul at boddie.org.uk Thu Nov 2 12:42:20 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 17:42:20 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <2783415.eSmmzF7rRR@desktop> References: <10942129.O9o76ZdvQC@desktop> <201711021311.38509.paul@boddie.org.uk> <2783415.eSmmzF7rRR@desktop> Message-ID: <201711021742.21424.paul@boddie.org.uk> On Thursday 2. November 2017 15.58.04 Volker Wysk wrote: > Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie: > > I imagine that we might need to dig deeper to see where Moin is spending > > all its time. Did you look at the following page, by the way...? > > > > https://moinmo.in/HowTo/Tune%20Performance > > Now I have. > > Can it because of using CGI instead of WSGI? No, not for one page load being slow, as in this case. Although Moin probably gets some benefit having processes active rather than needing to have them spawned when a request arrives, it isn't like it is really slow because it needs to have a lot of expensively-computed content sitting in some buffer ready for subsequent requests. In other words, Moin isn't really one of those Web applications that is so slow that it needs to permanently sit there taking up lots of memory, like a Java application server or something. > I've also tried "log_reverse_dns_lookups = False", but it's still slow. OK. Good to have that confirmed, anyway. Was this performance issue something that just started to happen, or is it that you finally made a big page and then saw that it was slow? Looking at your statistics again, I see that part of the block of time being consumed is this: Page.execute = 20.668s Now, this is supposedly concerned with just delivering the cached content (either generated previously or for this request). But I wonder whether it should really take very long given that what it should be doing is executing a compiled representation of the content. For me, it takes hardly any time at all within all the time used by a request. I'm wondering if there's a convenient way of profiling Moin. The wiki has some old pages about profiling, but I see that in the CGI script, there's a way of generating a profile: class Config(CgiConfig): # Server name - used to create .prof files name = 'moin' # Properties # Allow overriding any request property by the value defined in # this dict e.g properties = {'script_name': '/mywiki'}. ## properties = {} # Hotshot profile (default commented) ## hotshotProfile = name + '.prof' If you change the last part to something like this... hotshotProfile = "/tmp/moin.prof" ...this will hopefully generate profiling information (without complaining about permissions), and it can be converted to readable information as follows: hotshot2calltree -o /tmp/moin.tree /tmp/moin.prof We can probably even use other tools to visualise this nicely: kcachegrind /tmp/moin.tree Although my brief tests don't provide so much useful information, maybe there is something more interesting in any data you can generate. Paul From post at volker-wysk.de Thu Nov 2 13:13:23 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 18:13:23 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021742.21424.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop> <201711021742.21424.paul@boddie.org.uk> Message-ID: <13482194.bJLXHlSMRD@desktop> Am Donnerstag, 2. November 2017, 17:42:20 CET schrieb Paul Boddie: > Was this performance issue something that just started to happen, or is it > that you finally made a big page and then saw that it was slow? It just started at a point in time. I've had this very page with no such issues. > Looking at your statistics again, I see that part of the block of time being > consumed is this: > > Page.execute = 20.668s > > Now, this is supposedly concerned with just delivering the cached content > (either generated previously or for this request). But I wonder whether it > should really take very long given that what it should be doing is executing a > compiled representation of the content. For me, it takes hardly any time at > all within all the time used by a request. > > I'm wondering if there's a convenient way of profiling Moin. The wiki has some > old pages about profiling, but I see that in the CGI script, there's a way of > generating a profile: > > class Config(CgiConfig): > # Server name - used to create .prof files > name = 'moin' > > # Properties > # Allow overriding any request property by the value defined in > # this dict e.g properties = {'script_name': '/mywiki'}. > ## properties = {} > > # Hotshot profile (default commented) > ## hotshotProfile = name + '.prof' > > If you change the last part to something like this... > > hotshotProfile = "/tmp/moin.prof" > > ...this will hopefully generate profiling information (without complaining > about permissions), No luck on my side. Just to be sure: you mean adding the class definition above to /usr/local/share/moin/server/moin.cgi, and doing a "service apache2 restart". There was no "class Config(CgiConfig)" in there, before. > and it can be converted to readable information as > follows: > > hotshot2calltree -o /tmp/moin.tree /tmp/moin.prof > > We can probably even use other tools to visualise this nicely: > > kcachegrind /tmp/moin.tree > > Although my brief tests don't provide so much useful information, maybe there > is something more interesting in any data you can generate. > Volker From post at volker-wysk.de Thu Nov 2 13:22:04 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 18:22:04 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021742.21424.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop> <201711021742.21424.paul@boddie.org.uk> Message-ID: <13727271.YzzQCT0H0c@desktop> Hi I've had a closer look at the page's source code. There are some formatted sections ({{{...}}}), some <
>, but nothing suspicious... Volker From paul at boddie.org.uk Thu Nov 2 13:35:06 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 18:35:06 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <13482194.bJLXHlSMRD@desktop> References: <10942129.O9o76ZdvQC@desktop> <201711021742.21424.paul@boddie.org.uk> <13482194.bJLXHlSMRD@desktop> Message-ID: <201711021835.07205.paul@boddie.org.uk> On Thursday 2. November 2017 18.13.23 Volker Wysk wrote: > > No luck on my side. Just to be sure: you mean adding the class definition > above to /usr/local/share/moin/server/moin.cgi, and doing a "service > apache2 restart". There was no "class Config(CgiConfig)" in there, before. Sorry, I guess I was looking at a Moin 1.8 instance here, not 1.9. In 1.9, there are various profilers, but they need to be plugged into the WSGI pipeline (even if you're using CGI, Moin uses WSGI internally), and I've never done this myself. Maybe someone else has some experience with this or any of the other issues raised here. Paul From post at volker-wysk.de Thu Nov 2 13:43:43 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 18:43:43 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop> Message-ID: <1864701.xMRqLy2Rhn@desktop> Am Donnerstag, 2. November 2017, 13:20:48 CET schrieb Chris Freemesser: > On 11/02/2017 01:13 PM, Volker Wysk wrote: > > > It just started at a point in time. I've had this very page with no such issues. > I'm sorry that I've not been reading this thread very closely, but what > are the chances that it's not a problem with Moin itself, but that you > have a problem with your hard drive and repeated attempts to read a bad > sector are the reason you're seeing a delay? When I go to the page's directory in the moinmoin file-based database, and read the page, it works well: cd /usr/local/share/moin/data/pages/Rechner(2f)Einrichtung(2f)SSD/revisions cat 00000128 > /dev/null What else, and how else should be checked for problems with the hard drive...? I've bought that hard drive at the end of 2015. I don't think, it should fail so soon. Regards Volker From post at volker-wysk.de Thu Nov 2 13:50:03 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 18:50:03 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021835.07205.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop> <201711021835.07205.paul@boddie.org.uk> Message-ID: <2150673.NGskJkD61r@desktop> Am Donnerstag, 2. November 2017, 18:35:06 CET schrieb Paul Boddie: > On Thursday 2. November 2017 18.13.23 Volker Wysk wrote: > > > > No luck on my side. Just to be sure: you mean adding the class definition > > above to /usr/local/share/moin/server/moin.cgi, and doing a "service > > apache2 restart". There was no "class Config(CgiConfig)" in there, before. > > Sorry, I guess I was looking at a Moin 1.8 instance here, not 1.9. > > In 1.9, there are various profilers, but they need to be plugged into the WSGI > pipeline (even if you're using CGI, Moin uses WSGI internally), and I've never > done this myself. > > Maybe someone else has some experience with this or any of the other issues > raised here. What about that failing "moin maint cleancache" command? See my message of 14:28:17. Volker From paul at boddie.org.uk Thu Nov 2 13:54:48 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 18:54:48 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <1864701.xMRqLy2Rhn@desktop> References: <10942129.O9o76ZdvQC@desktop> <1864701.xMRqLy2Rhn@desktop> Message-ID: <201711021854.48315.paul@boddie.org.uk> On Thursday 2. November 2017 18.43.43 Volker Wysk wrote: > > What else, and how else should be checked for problems with the hard > drive...? > > I've bought that hard drive at the end of 2015. I don't think, it should > fail so soon. Hard drives can fail within a year if they are faulty. I had this kind of experience with a Western Digital Caviar Green drive a few years back (separate from the pathological head parking behaviour that wasn't advertised by the manufacturer because the Windows driver code was dealing with it, but where everyone else was on their own). Fortunately, the failure was relatively graceful. Try smartctl to see what the drive controller thinks: sudo smartctl --all /dev/sda Here, /dev/sda is the SATA device of interest. Use lsblk to see details of devices. Certainly, Chris is right in that hard disk failure can cause all sorts of bad blocking behaviour, although I'm not sure whether it would leave processes running at 100% CPU. Paul From post at volker-wysk.de Thu Nov 2 14:21:45 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 19:21:45 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711021854.48315.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <1864701.xMRqLy2Rhn@desktop> <201711021854.48315.paul@boddie.org.uk> Message-ID: <4279861.pR5KubLXJ9@desktop> Am Donnerstag, 2. November 2017, 18:54:48 CET schrieb Paul Boddie: > Try smartctl to see what the drive controller thinks: > > sudo smartctl --all /dev/sda > > Here, /dev/sda is the SATA device of interest. Use lsblk to see details of > devices. It's a long output, but nothing which looks particiularly suspicious. SMART Error Log Version: 1 No Errors Logged ---------snip--------- smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-97-generic] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD40EFRX-68WT0N0 Serial Number: WD-WCC4E7LACSDS LU WWN Device Id: 5 0014ee 20b871f92 Firmware Version: 82.00A82 User Capacity: 4.000.787.030.016 bytes [4,00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Nov 2 19:17:30 2017 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (52380) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 524) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 201 179 021 Pre-fail Always - 6916 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 133 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 078 078 000 Old_age Always - 16609 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 131 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 14 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 773 194 Temperature_Celsius 0x0022 105 097 000 Old_age Always - 47 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 15625 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. ---------snip--------- Bye Volker From cfreemes at ur.rochester.edu Thu Nov 2 13:52:43 2017 From: cfreemes at ur.rochester.edu (Chris Freemesser) Date: Thu, 2 Nov 2017 13:52:43 -0400 Subject: [moin-user] MoinMoin very slow In-Reply-To: <1864701.xMRqLy2Rhn@desktop> References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop> <1864701.xMRqLy2Rhn@desktop> Message-ID: On 11/02/2017 01:43 PM, Volker Wysk wrote: > What else, and how else should be checked for problems with the hard drive...? Depends on what operating system you're running, but something like 'chkdsk' for Windows or 'e2fsck' for Linux would be the tool to use. > I've bought that hard drive at the end of 2015. I don't think, it should fail so > soon. Never assume something like that...working in IT for the last 31 years (ugh, lol) has told me that hard drives can last anywhere between 10 minutes or 10 years after you take them out of the box. Chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Freemesser, Systems Administrator Dept. of Brain & Cognitive Sciences + The Center for Visual Science University of Rochester 255 Meliora Hall 585-275-0786 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From post at volker-wysk.de Thu Nov 2 14:29:40 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 19:29:40 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: References: <10942129.O9o76ZdvQC@desktop> <1864701.xMRqLy2Rhn@desktop> Message-ID: <5375651.y0MKLJsVfL@desktop> Hi I've copied the whole page, so new places on the hard disk should contain it. Same problem. Am Donnerstag, 2. November 2017, 13:52:43 CET schrieb Chris Freemesser: > On 11/02/2017 01:43 PM, Volker Wysk wrote: > > > What else, and how else should be checked for problems with the hard drive...? > > Depends on what operating system you're running, but something like > 'chkdsk' for Windows or 'e2fsck' for Linux would be the tool to use. Oh, I need to install a Kubuntu on an USB stick, so I can do that. > > I've bought that hard drive at the end of 2015. I don't think, it should fail so > > soon. > > Never assume something like that...working in IT for the last 31 years > (ugh, lol) has told me that hard drives can last anywhere between 10 > minutes or 10 years after you take them out of the box. :-( Volker From cfreemes at ur.rochester.edu Thu Nov 2 13:20:48 2017 From: cfreemes at ur.rochester.edu (Chris Freemesser) Date: Thu, 2 Nov 2017 13:20:48 -0400 Subject: [moin-user] MoinMoin very slow In-Reply-To: <13482194.bJLXHlSMRD@desktop> References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop> <201711021742.21424.paul@boddie.org.uk> <13482194.bJLXHlSMRD@desktop> Message-ID: On 11/02/2017 01:13 PM, Volker Wysk wrote: > It just started at a point in time. I've had this very page with no such issues. I'm sorry that I've not been reading this thread very closely, but what are the chances that it's not a problem with Moin itself, but that you have a problem with your hard drive and repeated attempts to read a bad sector are the reason you're seeing a delay? Chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Freemesser, Systems Administrator Dept. of Brain & Cognitive Sciences + The Center for Visual Science University of Rochester 255 Meliora Hall 585-275-0786 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From post at volker-wysk.de Thu Nov 2 16:54:44 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 21:54:44 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <10942129.O9o76ZdvQC@desktop> References: <10942129.O9o76ZdvQC@desktop> Message-ID: <3449944.O7kVYLoe2W@desktop> Hi! I've looked at the source code of the offending page again, und found what was the cause of the very small display of the page: There was a large block (all in one line) of giggerish, which looked like this: "" & quot; & amp; quot; & amp; amp; quot; & amp; amp; amp; quot; & amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp;" I have no idea of why I haven't noticed earlier. Removing this, solved one problem. The second is: Where does this come from? Could be a bug in the GUI editor. Bye and thanks, Volker From paul at boddie.org.uk Thu Nov 2 17:04:56 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 22:04:56 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <3449944.O7kVYLoe2W@desktop> References: <10942129.O9o76ZdvQC@desktop> <3449944.O7kVYLoe2W@desktop> Message-ID: <201711022204.57119.paul@boddie.org.uk> On Thursday 2. November 2017 21.54.44 Volker Wysk wrote: > Hi! > > I've looked at the source code of the offending page again, und found what > was the cause of the very small display of the page: There was a large > block (all in one line) of giggerish, which looked like this: > > "" & quot; & amp; quot; & amp; amp; quot; & > amp; amp; amp; quot; & amp; amp; amp; amp; quot; > & amp; amp; amp; amp; amp; quot; & amp; > amp; amp; amp; amp; amp; quot; & amp; amp; > amp; amp; amp; amp; amp; quot; & > amp; amp; amp; amp; amp;" > > I have no idea of why I haven't noticed earlier. > > Removing this, solved one problem. The second is: Where does this come > from? Could be a bug in the GUI editor. It may well have come from the GUI editor which probably gets even less attention than it used to. Once upon a time I had thought to replace it with something else - someone mentioned the whole contenteditable thing where the browser takes care of the editing functionality - but I never got round to it. Paul From paul at boddie.org.uk Thu Nov 2 17:11:19 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 2 Nov 2017 22:11:19 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <4279861.pR5KubLXJ9@desktop> References: <10942129.O9o76ZdvQC@desktop> <201711021854.48315.paul@boddie.org.uk> <4279861.pR5KubLXJ9@desktop> Message-ID: <201711022211.20245.paul@boddie.org.uk> On Thursday 2. November 2017 19.21.45 Volker Wysk wrote: > Am Donnerstag, 2. November 2017, 18:54:48 CET schrieb Paul Boddie: > > Try smartctl to see what the drive controller thinks: > > > > sudo smartctl --all /dev/sda > > > > Here, /dev/sda is the SATA device of interest. Use lsblk to see details > > of devices. > > It's a long output, but nothing which looks particiularly suspicious. I agree. The testing section doesn't have much in it... > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > LBA_of_first_error # 1 Short offline Completed without error > 00% 15625 - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing Maybe a short test might be helpful to confirm a lack of problems. I think this will do the trick, following the example given above: sudo smartctl -t short /dev/sda The drive information will be updated after a fairly short period to show the test result. Paul P.S. I think it was Load_Cycle_Count that indicated the pathological WD Caviar Green behaviour. Yours is at a healthy 773 whereas mine reached the hundreds of thousands before I turned off the bad behaviour. From post at volker-wysk.de Thu Nov 2 17:23:44 2017 From: post at volker-wysk.de (Volker Wysk) Date: Thu, 02 Nov 2017 22:23:44 +0100 Subject: [moin-user] MoinMoin very slow In-Reply-To: <201711022204.57119.paul@boddie.org.uk> References: <10942129.O9o76ZdvQC@desktop> <3449944.O7kVYLoe2W@desktop> <201711022204.57119.paul@boddie.org.uk> Message-ID: <9680534.RV3atjvHLj@desktop> Am Donnerstag, 2. November 2017, 22:04:56 CET schrieb Paul Boddie: > On Thursday 2. November 2017 21.54.44 Volker Wysk wrote: > > Removing this, solved one problem. The second is: Where does this come > > from? Could be a bug in the GUI editor. > > It may well have come from the GUI editor which probably gets even less > attention than it used to. And there are some more issues... > Once upon a time I had thought to replace it with > something else - someone mentioned the whole contenteditable thing where the > browser takes care of the editing functionality - but I never got round to it. Keep hacking Volker From post at volker-wysk.de Mon Nov 13 07:33:08 2017 From: post at volker-wysk.de (Volker Wysk) Date: Mon, 13 Nov 2017 13:33:08 +0100 Subject: [moin-user] "file://" links in wiki pages Message-ID: <9700091.a8W70hacDW@desktop> Hi! "file://"-Links in Wikipages don't work. There is no response to clicking one at all. For instance: Create some file /tmp/hallo.txt, and link to it in a Moin page: [[file:///tmp/hallo.txt]] Then the HTML page contains the following: file:///tmp/hallo.txt When this is isolated, on a page by itself, the link works fine. However, if it occurs enclosed in the rest of the Moin HTML page, the link is dead. It doesn't matter if you use "file:/" or "file:///". Bye Volker From post at volker-wysk.de Mon Nov 13 08:13:23 2017 From: post at volker-wysk.de (Volker Wysk) Date: Mon, 13 Nov 2017 14:13:23 +0100 Subject: [moin-user] "file://" links in wiki pages In-Reply-To: <9700091.a8W70hacDW@desktop> References: <9700091.a8W70hacDW@desktop> Message-ID: <9284264.75apfn2clC@desktop> Am Montag, 13. November 2017, 13:33:08 CET schrieb Volker Wysk: > When this is isolated, on a page by itself, the link works fine. However, > if it occurs enclosed in the rest of the Moin HTML page, the link is dead. Might this be for securtiy? "file://" links don't make much sense in a multi user/multi machine environment... You need to upload the link target, such that it becomes an attachment, which can be linked. Be it as it may, a message would be good, when clicking on a "file://" link, and such aren't supported. Volker From lists at hcf.yourweb.de Sat Nov 25 08:37:32 2017 From: lists at hcf.yourweb.de (lists at hcf.yourweb.de) Date: Sat, 25 Nov 2017 14:37:32 +0100 (CET) Subject: [moin-user] =?utf-8?b?fHw8dGFibGVjbGFzcz0i4oCmIj4gcHJvY2Vzc2lu?= =?utf-8?q?g_broken_in_Moin_1=2E9=2E9?= Message-ID: <1283338094.251949.1511617052336@ox.hosteurope.de> I found a bug in Moin 1.9.9, but my account for the moinmo.in wiki has been deleted and I cannot register a new account as I don't know the magic password. So I am posting this here and hope some developer sees this. :) MoinMoin-Wiki Markup Source: || '''Table Header''' || || Table Data || Expected output (as seen in MoinMoin 1.9.7 and below): ?
? Actual output from MoinMoin 1.9.9: ?
? -- Christian Taube From paul at boddie.org.uk Sat Nov 25 09:35:00 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Sat, 25 Nov 2017 15:35:00 +0100 Subject: [moin-user] || processing broken in Moin 1.9.9 In-Reply-To: <1283338094.251949.1511617052336@ox.hosteurope.de> References: <1283338094.251949.1511617052336@ox.hosteurope.de> Message-ID: <201711251535.01621.paul@boddie.org.uk> On Saturday 25. November 2017 14.37.32 lists at hcf.yourweb.de wrote: > I found a bug in Moin 1.9.9, but my account for the moinmo.in wiki has been > deleted and I cannot register a new account as I don't know the magic > password. So I am posting this here and hope some developer sees this. :) > > MoinMoin-Wiki Markup Source: > || '''Table > ||Header''' || Table Data > |||| > > Expected output (as seen in MoinMoin 1.9.7 and below): > > ? >
? > > > Actual output from MoinMoin 1.9.9: > > ?
? Quoting issues are almost always frustrating. Looking at the differences between 1.9.7 and 1.9.9, there are few changes to the parser and formatter code, but I did spot something interesting in one of the tests: https://bitbucket.org/thomaswaldmann/moin-1.9/commits/465cb6f5c6d7a88e5c3685d86ad20ff0e41318d5#chg- MoinMoin/parser/_tests/test_text_moin_wiki.py The commit message is useful because it indicates that Werkzeug got upgraded and had changed its behaviour. I haven't chased down the sequence of operations that might involve the escape function, however. What is also odd is that the above looks like double-quoting. Paul From Mark.Martinec+moin at ijs.si Sat Nov 25 19:26:50 2017 From: Mark.Martinec+moin at ijs.si (Mark Martinec) Date: Sun, 26 Nov 2017 01:26:50 +0100 Subject: [moin-user] =?utf-8?b?fHw8dGFibGVjbGFzcz0i4oCmIj4gcHJvY2Vzc2lu?= =?utf-8?q?g_broken_in_Moin_1=2E9=2E9?= In-Reply-To: <201711251535.01621.paul@boddie.org.uk> References: <1283338094.251949.1511617052336@ox.hosteurope.de> <201711251535.01621.paul@boddie.org.uk> Message-ID: <624de859753cd3a11a84400f03ed9ff4@ijs.si> > On Saturday 25. November 2017 14.37.32 lists at hcf.yourweb.de wrote: >> I found a bug in Moin 1.9.9, but my account for the moinmo.in wiki has >> been >> deleted and I cannot register a new account as I don't know the magic >> password. So I am posting this here and hope some developer sees this. >> :) >> >> MoinMoin-Wiki Markup Source: >> || '''Table >> ||Header''' || Table >> Data >> |||| >> >> Expected output (as seen in MoinMoin 1.9.7 and below): >> >> ? >>
? >> >> Actual output from MoinMoin 1.9.9: >> >> ?
? 2017-11-25 15:35, Paul Boddie wrote: > Quoting issues are almost always frustrating. Looking at the > differences > between 1.9.7 and 1.9.9, there are few changes to the parser and > formatter > code, but I did spot something interesting in one of the tests: > > https://bitbucket.org/thomaswaldmann/moin-1.9commits/465cb6f5c6d7a88e5c3685d86ad20ff0e41318d5#chg-MoinMoin/parser/_tests/test_text_moin_wiki.py > > The commit message is useful because it indicates that Werkzeug got > upgraded > and had changed its behaviour. I haven't chased down the sequence of > operations that might involve the escape function, however. > > What is also odd is that the above looks like double-quoting. > > Paul This double quoting bug is frustrating. It has already been reported in June 2017: https://mail.python.org/pipermail/moin-user/2017-June/009765.html Apart from downgrading Werkzeug, I haven't found a better solution. Mark From paul at boddie.org.uk Wed Nov 29 10:23:48 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 29 Nov 2017 16:23:48 +0100 Subject: [moin-user] || processing broken in Moin 1.9.9 In-Reply-To: <624de859753cd3a11a84400f03ed9ff4@ijs.si> References: <1283338094.251949.1511617052336@ox.hosteurope.de> <201711251535.01621.paul@boddie.org.uk> <624de859753cd3a11a84400f03ed9ff4@ijs.si> Message-ID: <201711291623.49485.paul@boddie.org.uk> On Sunday 26. November 2017 01.26.50 Mark Martinec wrote: > > This double quoting bug is frustrating. It has already been reported > in June 2017: > > https://mail.python.org/pipermail/moin-user/2017-June/009765.html > > Apart from downgrading Werkzeug, I haven't found a better solution. I just tried reproducing it with both 1.9.9 and the current tip revision, and I cannot manage it: the tables are rendered as expected. So we need to find a way of identifying the circumstances under which this occurs. Do either of you (or does anyone else who experiences this) have Werkzeug installed elsewhere? The importing should be confined to Moin's own bundled libraries, but I don't trust Python's import mechanisms to always do the right thing. I'm using Python 2.7.3 on Debian Wheezy to test this. Perhaps there might be a Python version influence. Paul P.S. I also saw that the bundled passlib changed between 1.9.9 and tip, breaking the setup script, so I just posted a patch to the moin-devel list. P.P.S. If you ever have problems with phantom packages when installing Moin, be sure to remove the distutils build directory. From lists at hcf.yourweb.de Wed Nov 29 10:37:37 2017 From: lists at hcf.yourweb.de (Christian Taube) Date: Wed, 29 Nov 2017 16:37:37 +0100 (CET) Subject: [moin-user] =?utf-8?b?fHw8dGFibGVjbGFzcz0i4oCmIj4gcHJvY2Vzc2lu?= =?utf-8?q?g_broken_in_Moin_1=2E9=2E9?= In-Reply-To: <201711291623.49485.paul@boddie.org.uk> References: <1283338094.251949.1511617052336@ox.hosteurope.de> <201711251535.01621.paul@boddie.org.uk> <624de859753cd3a11a84400f03ed9ff4@ijs.si> <201711291623.49485.paul@boddie.org.uk> Message-ID: <1214722719.294779.1511969857676@ox.hosteurope.de> > Paul Boddie hat am 29. November 2017 um 16:23 geschrieben: > > > On Sunday 26. November 2017 01.26.50 Mark Martinec wrote: > I just tried reproducing it with both 1.9.9 and the current tip revision, and > I cannot manage it: the tables are rendered as expected. So we need to find a > way of identifying the circumstances under which this occurs. At the time I started the topic here I was able to reproduce this behaviour on the wiki running at http://moinmo.in/ Although I don?t have an account there anymore, I was able to edit and preview the Sandbox page - I just couldn?t permanently save the page. But the preview page showed the additional &dquot; in the html source code. ? Christian Taube From paul at boddie.org.uk Wed Nov 29 11:28:16 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 29 Nov 2017 17:28:16 +0100 Subject: [moin-user] || processing broken in Moin 1.9.9 In-Reply-To: <1214722719.294779.1511969857676@ox.hosteurope.de> References: <1283338094.251949.1511617052336@ox.hosteurope.de> <201711291623.49485.paul@boddie.org.uk> <1214722719.294779.1511969857676@ox.hosteurope.de> Message-ID: <201711291728.17021.paul@boddie.org.uk> On Wednesday 29. November 2017 16.37.37 Christian Taube wrote: > > At the time I started the topic here I was able to reproduce this behaviour > on the wiki running at http://moinmo.in/ > > Although I don?t have an account there anymore, I was able to edit and > preview the Sandbox page - I just couldn?t permanently save the page. But > the preview page showed the additional &dquot; in the html source code. I just tried this: https://moinmo.in/action/recall/WikiSandBox?action=recall&rev=4103 Actually, I must be mistaken. If you look at the source, there is superfluous quoting going on. But then again, the styling does seem to work, or at least the colour styles get parsed. Well, I'll get back to looking at the code again, I guess. Paul From paul at boddie.org.uk Wed Nov 29 11:57:16 2017 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 29 Nov 2017 17:57:16 +0100 Subject: [moin-user] || processing broken in Moin 1.9.9 In-Reply-To: <201711291728.17021.paul@boddie.org.uk> References: <1283338094.251949.1511617052336@ox.hosteurope.de> <1214722719.294779.1511969857676@ox.hosteurope.de> <201711291728.17021.paul@boddie.org.uk> Message-ID: <201711291757.16958.paul@boddie.org.uk> On Wednesday 29. November 2017 17.28.16 Paul Boddie wrote: > > Actually, I must be mistaken. If you look at the source, there is > superfluous quoting going on. But then again, the styling does seem to > work, or at least the colour styles get parsed. > > Well, I'll get back to looking at the code again, I guess. OK, I now see the problem. After considering what the attributes look like as they pass through the formatter and parser code, it turned out that they were always double-escaped. This led me to the following in the parser code: def _getTableAttrs(self, attrdef): ... attr, msg = wikiutil.parseAttributes(...) See: MoinMoin/parser/text_moin_wiki.py This in turn led me to the offending function: def parseAttributes(request, attrstring, endtoken=None, extension=None): ... # safely escape and quote value if val[0] in ["'", '"']: val = escape(val) else: val = '"%s"' % escape(val, 1) See: MoinMoin/wikiutil.py Since Werkzeug decided to offer only one kind of escaping, deprecating the quote parameter, any escape invocation will now escape quotes regardless of whether the quote parameter is specified or what its value is. So here, where we don't want the quotes to be escaped, Werkzeug will just escape them anyway. (Honestly, it is absurd that the Werkzeug code actively contradicts any supplied value, offering a feeble "deprecation error" as it does so.) I guess that the idea was to use werkzeug.utils.escape instead of cgi.escape in Moin, but since it breaks compatibility, this idea doesn't make sense any more. So I'm almost inclined to think that the code should go back to using cgi.escape, not just in the above function but more widely. However, we don't know which escape invocations rely on extra functionality in Werkzeug's implementation such as returning an empty string if supplied with None, or doing some coercions to strings and using special __html__ methods. The latter two things seem less likely within Moin code, especially since Moin was originally using cgi.escape and was thus oblivious to Werkzeug's magic. So, there's a quick fix and a potentially better fix that might deal with unnoticed breakage. Paul