My problem is is that paperclip saves the attachments appropriately, and I assume imagemagick is doing something right. With no errors returning, the images never finish processing.
Does anyone know a way to see what's backgrounding?
Or specifically a way to review imagemagick's processes?
tail -f log/delayed_job.log for "backgrounding"
And imagemagick's processes can be seen in your regular production log.
tail -f log/production.log
Related
I have the Math extension installed in my MediaWiki 1.19. After I updated Ubuntu Server from 12.04 to 14.04 something seems to have messed it up and it has stopped working. Basically I get the following error when I try to display anything between the <math> and </math> tags:
Failed to parse (PNG conversion failed; check for correct installation
of latex and dvipng (or dvips + gs + convert))
I have tried the common troubleshooting that one can find online regarding this issue, and have recompiled texvc to check if that fixed the issue. The texvc executable in the extensions/Math/math directory seems to do its job when invoked from the command line. I have obviously checked that all the other executables (latex, dvipng, etc.) work as they should.
When I try to render math from my wiki, the corresponding *.tex file is created in images/tmp with the correct latex code in it, but nothing else happens.
The problem seems to be related to texvc having trouble invoking latex and dvipng.
What could be causing this issue and how can I fix it?
Well, I figured it out. Basically, any shell command is passed by a security filter. So in practice, texvc is executed by Mediawiki through bin/ulimit4.sh:
#!/bin/bash
ulimit -t $1 -v $2 -f $3
eval "$4"
where $4 is the actual texvc command being run and $2 is the amount of memory allowed for this process. The memory that comes by default is 102400 KB (exactly 100MB), which seems to be insufficient for this process to run. The amount of memory can be set in LocalSettings.php with the variable $wgMaxShellMemory. In my case I set it to 300MB, $wgMaxShellMemory = 307200;, which seems to be enough.
Why this small process of generating a png needs so much memory I do not know.
The reason why this stopped working after updating to Ubuntu 14.04 probably has to do with some newly shipped version of either latex, dvipng, convert, etc. requiring more memory than it did with the version that came with Ubuntu 12.04.
I clean hacked Wordpress installations for clients on a regular basis, and I have a set of scripts that I have written to help me track down where the sites are hacked. One code snippet that I use on a regular basis worked fine on Ubuntu, but since switching to Fedora on Friday has quite behaving as expected. The command is this:
grep -Iri --exclude "*.js" "eval\s*(" * | grep -rivf ~/safeevals.txt >../foundevals.txt;
What it is supposed to happen (and did happen when I was using Ubuntu): grep through all non-binary files, excluding Javascript includes, for all occurances of the eval() function, then perform a negative match on a line by line basis against all known occurances of the eval() function in a vanilla installation of Wordpress (the patterns of which are in ~/safeevals.txt).
What is actually happening: The first part is working fine, as I ran it separately and it did find all instances of eval() in the installation. However, instead of greping through those results, after the pipe is it re-grepping through all of the files, returning a negative match of ~/safeevals.txt (ie. pretty much every line of every file in the installation).
Any idea why the second grep isn't acting on the piped data, or what I need to do to fix it? Thanks.
-Michael
Just tested on my Debian box: apparently, grep -r likes to assume a default argument of .. I am really wondering if that behaviour is valid. Anyway, I guess dropping the -r option from the second grep command will fix it.
Edit: rgrep defaulting to $PWD seems to be a recent change in grep, see this discussion on unix.stackexchange and the link there to the commit in the upstream grep code repository.
While generating a large site using the ToolTwist Controller, the server hangs. Using ps -ef I can see that there is an ImageMagick 'convert' command that never seems to finish. If I kill the convert process, the generate continues.
If I get the full convert command from the log file or using ps, I can run it from the command line with no problem. Each time I run the generate process in the Controller it gets stuck in a different place.
How often it hangs seems to be sporadic, and only occurs maybe every 1,000 images.
I'm running OSX 10.7.3 on a Macbook Pro.
This is a known bug in ImageMagick - see http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=19962
The solution is to define an environment variable:
export MAGICK_THREAD_LIMIT=1
You'll need to do this before starting the Controller's tomcat server.
Reading a Rails log with vim, we can see a colored log.
But when we use tail -f or less to watch the log, it isn't colorized anymore. Is there any way to see the colored log with tail or less or whatever?
pass -R to less for it to let colour escape sequences pass through, i.e.
less -R log/development.log
This should result in them being displayed in colour, assuming you are using the proper terminal type
tail -f log/development.log | ccze -A
You may need to install ccze
sudo apt-get install ccze
it works better, not ideal but works
You can't do that out of the box, since tail and less know nothing about Rails, and logs are saved a simple text files. You could use regular expressions to colorize output but I doubt it's worth the trouble.
EDIT: see alfonso's comment for some alternatives.
i am developing on 5 different rails projects, plus also refactoring some (moving from older rails versions to 2.3) - what is the best way to extract the error information from the logfiles, so i can see all the depreciation warnings, runtime errors and so on, so i can work on improving the codebase?
are there any services or libraries out there you can recommend, that actually help with rails logfile parsing?
Read about grep linux command.
http://www.cyberciti.biz/faq/howto-use-grep-command-in-linux-unix/
I don't know what error log format is in Rails, but I guest every row with warning or error contain "warning" or "error" word.
Then it would be like this:
grep -E "error|warning" logfile.txt
for bot error and warnings
grep "error" logfile.txt
for errors
grep "warning" logfile.txt
for warnings
and if you want to see new errors and warnings in real time, try this
tail -f logfile.txt | grep -E "error|warning"
tail -f logfile.txt | grep "error"
tail -f logfile.txt | grep "warning"
Hope I could help you ;) and I hope that I'm not wrong about logs format in Rails
I've found the request-log-analyzer project to be very useful.
You can certain grep the log to find errors and dump them out, but this does an excellent job of gathering all the information about the different actions and how long they take.
Here's some sample output.
This is the first thing I run when I get a call saying "my site is slow and I need help fixing it."
Hoptoad and/or Exceptional are great for ongoing errors, but they don't track log running requests. Something like New Relic is good for that.
I use hoptoadapp, http://www.hoptoadapp.com/pages/home there is a free flavor, it logs your error messages to their database, and they provide an easy to use interface. All you have to do is install this plugin: http://github.com/thoughtbot/hoptoad_notifier.
It won't help for past errors, but it is great for isolating problems with a currently running app.