Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
I am struggling with “500 Internal Server Errors” that appear when saving and/or displaying the notes the I am writing.
I have been trying hard to determine what exact line causes the error, but I don’t recognize any systematics.
I was suspecting that it has to do with equation references as in
(eq:EquationName)
but I can’t isolate this as the source of the problem.
First I get the errors upon saving (after hitting “submit”) but after a while they also affect content that was previously already saved succesfully.
For instance right now on my sytem just asking the Sandbox to display produces a “500 Internal Server Error”.
Sandbox is displaying for me right now.
Thanks. Yes, the page now displays on my system, too. Unfortunately, I still get the internal server error when trying to save my new version. This is very frustrating…
It’s displaying for me as well, but I was able to verify your issues with saving. It looks like a Maruku bug, I’ve reported it so we’ll see what happens.
And in fact right now, right after trying to save the expanded version, also showing the page gives me an Internal Server Error again.
I can reproducibly trigger a “500 Internal Server Error” by writing
(eq:EquationName)
when “EquationName” has not been defined. That’s why I speculated it has something to do with this.
Okay, I have now removed all
(eq:
from my code, and now it does save. Now I only have to find in which of 69 occurences I have a misprint…
I have gotten closer, maybe somebody can help me:
I have turned all occurences of
(eq:something
into
(eqs:something
to make the parser skip them, and then I re-introduced them one-by-one to see which one is the first to cause a problem.
The first one that causes the problem is the one in the line
Now we regard this as a _[[graded module]]_ over $\Omega^{0,0}_{\Sigma,cp}(E,\varphi)$ (eqss:FunctionsOnInfinitesimalNeighbourhoodOfBackgroundSolution) concentrated in degree $-1$:
But the problem is not that the anchor
FunctionsOnInfinitesimalNeighbourhoodOfBackgroundSolution
is undefined. It seems properly defined.
If anyone wants to give it a try: take the page source here and try to replace the occurence of
(eqss:
or the following occurences of
(eqs:
into proper
(eq:
Can you do it so that the output works? Or else, what needs to be changed for this to happen?
(Best to do this in the Sandbox, but presently the Sanbox again gives me Internal Server Error no matter what.)
Thanks, Tim. Right, what makes this really fiddly to pin down is that there is some time dependency involved.
For instance I just tried resaving the entry at geometry of physics – A first idea of quantum field theory and what previously worked gave me an error message now! So now I turned one more occurence of
(eq:
into
(eqs:
to make it work. Sigh.
But Tim, if you have energy to help: What happens to you when you open the Sandbox and replace the first occurence of
(eqs:
with
(eq:
?
I replaced the first one that I found, which was (eqs:ConstantSectionOfTrivialShellBundle), …no problem. Then I replaced the next one which was (eq:FunctionsOnInfNbh) and I got the error.
Update: that may have been wrong as I found another (eqs:ConstantSectionOfTrivialShellBundle and editing that gave Error 502 Ray ID: 3ab8f03d7a530b7b • 2017-10-10 10:37:00 UTC and said it was an error that was at ncatlab.org.
I have replaced eq by eqs back in those two situations, but it still is giving 502. I cleared my local cache just to make sure and also tested on Safari. Same result . (I did not think it was a browser issue merely wanted to check I was not calling up some faulty version from my cache.)
I should perhaps point out that the errors I am getting are ‘Bad Gateway’ ones (502) not internal server error (500).
I made some other changes to another entry and there was no problem.
(Edited 38 minutes later: Has someone done something? I was unable to see the Sandbox after my edits. Now I can.)
Perhaps further progress: I tried to see if there was a case somewhere of an (eq which worked. I tried to search in the Lab for (eq and this is what I got:
Oops! Please report this on the nForum (in the Technical category), giving as precise details as you can as to what triggered the error.
and a
500 Internal Server Error
Tim, thanks for your efforts!
At least you are seeing the same kind of erratic behaviour as I get on my side, that’s already good to know.
Adeel says he has reported this as a bug now.
I think it might be fixed now. Can you check if you’re still getting errors?
I tried editing David Roberts (to add one extermal link) and I get a 500 sever error. When I tried to cancel the edit I get
XML Parsing Error: junk after document element Location: https://ncatlab.org/nlab/show/David+Roberts Line Number 3, Column 1:
<p>Back to the <a href="/">Home Page</a>.</p>
^
I’m getting that XML parsing error on trying to view a bunch of pages, like category theory.
I just looked at over category from a Google search and got
XML Parsing Error: junk after document element Location: https://ncatlab.org/nlab/show/over+category Line Number 3, Column 1:
so something is sick out there!!!
Other articles seemed to work alright. (Edit: I tell a lie!!!! Several other articles called up from a Google search page gave the same error.)
While in Sandbox all the
(eqs:EquationLabel)
got changed back to the proper
(eq:EquationLable)
without producing an error, now none of the equation numbers get rendered: all the “(eq:EquationLabel)” appear verbatim in the output text.
Also, every numbered equation carries the same number “(1)”, at the moment.
Oops. That XML parsing error should be fixed now, but I’m not sure why the Maruku “fix” broke the equation numbers.
Ok, I think it is fixed now. All the equation numbers are rendering except (eq:FunctionsOnInfinitesimalNeighbourhoodOfBackgroundSolution), which indeed doesn’t seem to be defined (presumably FunctionsOnInfNbh was intended).
Thanks, Adeel!
Sorry, but one more thing: now none of the maths is rendered anymore…
I temporarily broke all the math everywhere for a moment, should be back to normal now…
That was quick!
Sorry again: now on re-saving I again get the “500 Internal Server Error”.
Sorry, I was in the middle of making the temporary fix more permanent and some unexpected complications arose. Anyway, I believe everything should be working now (and I’m not going to touch anything for a bit unless you point out otherwise).
For the record, the nLab is now using this forked version of Maruku.
Hm, that’s pretty bad. I’ll have to revert the change I made then for now (so the equation reference issues will be back again).
[edit: going to try something, give me a couple minutes]
Well the default library that Maruku was using for string scanning had the bug related to equation numbering. When I switched to a different string scanning library, this issue was fixed but then we started getting other errors on a lot of pages. The reason turned out to be that the second library wasn’t equipped to handle multibyte character sets like UTF-8. Once I figured out what was going on, it turned out to be easy to fix.
I see, interesting.
By the way, is there a maximum length for anchor names (either for defs/props or for equations)?
I like to use long explicit anchor names, but at some point I got worried that this is maybe causing some errors.
I’m not aware of any restriction on the length of anchor names, no.
Still something wrong with the Unicode I think: at promonoidal category the RIGHTWARDS ARROW WITH VERTICAL STROKE characters ⇸ in the source show up on the page as three “Unknown character”s. Maybe a multibyte-ness problem?
Also, five minutes back when saving again in the Sandbox, the “500” error suddenly was back. Trying again, it works now.
There was a similar time-dependency of the problem before. Is that somehow explained by the fix that you, Adeel, have made, or, otherwise, is it maybe an indication that there is a second, parallel, problem?
@33: I’m not sure that was caused by the latest changes. For example, using unicode in math commands doesn’t work here either:
and there haven’t been any changes to the nForum configuration. I would assume it’s just an iTeX issue. To be honest, I don’t even know whether this works in LaTeX. Of course in this instance it can be fixed by changing ⇸ to \twoheadrightarrow.
@34: It could be a completely separate issue. I would have to reproduce the bug in order to diagnose it, which I haven’t been able to do when I tried just now.
Sure, thanks. The moment I receive an error message from the server, I suppose in that moment some stack trace is written to the logs? Would it help if, next time, I try to give the precise time when the error occurs, so that it can be found in the logs?
That would help, yeah.
Re #35, well it was caused by some change, because it used to work. For instance, you can see on my personal page that I recorded how to make barred arrows (which are not the same as two-headed arrows) and esh.
(Unicode does work in math mode in LaTeX, as long as you import the right packages.)
Oh, I think I see. Maybe unicode in math never used to work in iTeX, but what did (and still does) work is HTML character entities in math: $A ⇸ B$ gives . What appears to have happened is that all the HTML character entities on nLab pages have been replaced by their actual unicode equivalent characters. This is worrisome, since it seems like it might be rather hard to globally undo.
Yeah, good catch.
What appears to have happened is that all the HTML character entities on nLab pages have been replaced by their actual unicode equivalent characters.
This is the inadvertent result of a script I ran to fix any encoding issues in all the pages. I made a backup we could restore to, but I’m not sure unicode characters instead of HTML entities is a bad thing. I’d rather fix the iTeX issue, which seems like it shouldn’t be much work.
The conversion of < to < has also broken the text of all the “history” pages. When a page A needs to be removed in a merge, we rename it to A > history and replace its content with < [[B]] where B is the page that it was merged into; the latter displays as “< B” with a link. But now all the history pages contain < [[B]] instead, which does not display as anything, because iTeX parses it as the beginning of an HTML tag I guess.
The instructions for this are at HowTo#merging. But actually those instructions are now also broken! Did backquotes get changed to forward quotes at the same time? Backquotes must be in lots of other places on the lab too.
Maybe this is related: Now I get “Error 502: Bad Gateway” when asking for “latest changes” on the file, specifically when clicking on this link here:
https://ncatlab.org/nlab/revision/diff/geometry+of+physics+–+A+first+idea+of+quantum+field+theory/45
So do I.
re #41:
I now see that this is somewhat urgent: Check out any of the entries such as shape modality.
Yes, if we can’t get the iTeX issue fixed very quickly, and also do something about the <s that used to be <s, then I think we should restore from the backup (that is, as long as it won’t be too hard to merge in all the intentional changes made since the backup).
I have emailed Adeel yesterday.
I wish all this trouble would not be solely on his shoulders, I feel a bit bad about this.
These days I ran into a gentleman over on “PhysicsForums-Insights” who shows tremendous energy in helping with IT issues. Notably, he has written now a script that turns nLab entries section-wise into PhysicsForums-Insights articles, complete with everything, notably Definition/Proposition numbering and hyperlinked refs to them that work across articles.
Anyway, what I want to say is that maybe eventually we might find more people who could lend Adeel a hand in the more time-consuming aspects of administrating the nLab.
This seems unchanged in over a month. The > history pages don't work, Unicode in iTeX doesn't work and the HTML character entities have not been restored, and in general the Lab is currently unreadable in random spots (shape modality remains a great example).
If we have to restore from backup, this is going to get harder and harder as time goes on.
Unfortunately the “we” in “if we have to restore” is an illusion. I have recently tried to bring more people into nLab admin, but somehow it doesn’t work. If you or anyone has energy to help, which would be greatly appreciated, please email Adeel Khan.
In the offline email discussion, at least two of us (myself and Igael) have made an offer to try something. Someone, or maybe the steering committee, needs to make a decision to give someone, say Igael, a clear mandate to try out their ideas. It would also be helpful if Adeel contributed to that discussion.
Hi Richard, one possibility would be to go and fix the Maruku bugs. No mandate necessary for that, everyone will appreciate to see them fixed.
The other possibility is to set up a parallel wiki and convert our database of entries to that. Once that alternative exists and works better, again nobody will object to switching (I suppose it should be easy to arrange that all our url-s remain as the are, and just point to another installation at some point).
If you asked me (or Mike), I would suggest to simply (?) write a converter from Instiki to whatever it is that WorkingWiki reads in. But the trick in this business is not to ask too many people for their opinion, just do it.If the result is good, everyone will be happy to use it. I’ll be enthusiastic.
Hi Urs, thanks for the reply. If nothing happens in the meantime, I might be willing to try write something which looks more or less as the nLab does now, but with a different, more maintainable backend underneath. Responses to this suggestion have not exactly been overwhelmingly enthusiastic, though, so I’ll wait a bit. As I have mentioned, the current source code is messy in my opinion, and not structured in an easily maintainable way, so it is hard to find the motivation to delve into it; nevertheless, again, I may do so if nothing happens.
In the meantime, a half-decent system should have some logs, which should provide some more information as to what is causing the 500 error. If you can give me access to the server (so that I can ssh into it), I can try to dig into it if you like, to try to find the logs if they exist.
Access to the database would also be good. Just send the details over email if you’d like me to take a look.
E.g. because an obvious thing to check with regards to the problem with saving very large entries is how they are being stored in the database and how they are being fetched, to exclude the possibility that there is not simply some obvious limit that is being exceeded.
Right, that’s why i was starting that email thread. Adeel needs to give you this information, because I don’t know. I trust he will find time to get back to us at some point. But best if you send him a personal email.
Thanks for your help!
Let me second Urs’ thanks. I know zero about the technical/code/database things required, so I’m left hoping “someone” volunteers to help.
You’re welcome, I have sent Adeel a personal email now.
Adeel and Richard have figured out/done something regarding the problem with unicode symbols.
It looks like all symbols display correctly now. But everbody please check.
Awesome! It looks like all the unicode characters have been turned back into HTML entites.
The problem mentioned in #42 above is still there, though.
Thanks very much, Adeel and Richard!!
Adeel did almost all the work here, he deserves great thanks indeed for all the hard work he is doing. He ended up indeed reverting back to HTML entities. I contributed only pointing out where the actual problem was, which was in itex2MML, not in Maruku as originally thought. I suggested a one line change which Adeel implemented; it improved the situation but did not solve the problem completely, and then we felt that since itex2MML is designed to handle html entities, and since we now knew that it was in itex2MML that the problem lay, that it would be best to do the reversion rather than attempt to elaborate upon the one line fix.
We have a plan for solving #42, I will probably take that one, later this week some time.
It’s amazing how much progress there is now. I am glad that you are helping with this!
I believe the problem mentioned in #42 is now fixed. For example:
This may have caused a problem: Inside entries the symbol
>
is used to create indented italicized environments (probably meant for quotes but used by us also for side remarks). Many of these have been turned now into
>
which instead of causing indented italicized context makes them appear as “>”.
See for instance the top line at action.
Strangely, other entries are not affected, see for instance the first line at theory.
We may not have needed any > changed into >, only < changed into <. Offhand, I can't think of any reason that we use >, so it might be safe to mass-change all > to >. But I could be wrong about that!
My best guess as to why theory was spared but action was not is that theory begins with a blank line. (There's a bugfeature of Markdown that makes it a good habit to begin every page with a blank line. But for some reason I've never adopted this habit with History and Empty pages, probably because they are so minimal, and in particular will never trigger this feature.) Perhaps Adeel only reverted things in which the < or > was the first character in the source? That could make it pretty easy to revert!
There are >s that became >s that aren’t at the top of a page, see for instance the quote from Mac Lane about “brash or speculative abstraction” at category theory.
Offhand I can’t think of any reason to use > instead of >. The only reason I know of to use < instead of < is that < can be mistakenly interpreted as the beginning of an HTML tag, which isn’t the case for >. I guess if for some reason you wanted to start a line with a > character that would display as-is instead of making the paragraph into a blockquote, you could write >, but that use-case seems vanishingly rare. So if there’s no more principled solution, I think mass-changing all > to > would be an improvement.
An aside, though: perhaps instead of misusing the blockquote syntax > for hatnotes, we ought to introduce a special CSS for them, analogous to our query and standout boxes.
An aside, though: perhaps instead of misusing the blockquote syntax > for hatnotes, we ought to introduce a special CSS for them, analogous to our query and standout boxes.
That’s a good point, we should introduce a hatnote-box environment.
On the other hand, many entries do use “>” for actual blockquote, too. I keep fixing them as I happen upon them, but it affects may entries.
I agree, the > problem does need to be fixed. I was just pointing out as an aside that we should also stop misusing it for hatnotes.
I will try to take a look at this some time this week along with the issue Zoran mentioned.
I have now (with heart somewhat in mouth) attempted to fix this, by mass-replacing > by > as suggested. I have done it in the revision history as well. Please check if things look OK. Please also let me know if there any problems with other symbols.
(The reason for this being heart in mouth is that I used a script which edited the database, and since I was doing the revision history as well, there is ’no going back’ if I got it wrong; or rather we’d have to use the git backup. Of course I tested as carefully as possible first…!)
Hmm, the substitution seems to have gone OK, but some quotes seem not to be displaying anyway. Am taking a look.
See for example the quote by Lawvere at modal type theory. The source looks fine, but still the quote is not displayed.
Actually, modal type theory is fine in the revision history, so there’s probably just something extra I need to do for the live pages. Am looking into it.
Appears to be a caching issue. I have now cleared part of the cache, and things look OK now. Please check.
Thanks!! The pages linked above look good; anyone who happens across anything that looks wacky can bring it up.
1 to 76 of 76