yeah you read that title right. can you believe it? I fought with my computer for an hour early this morning, installed a super fresh kernel, played with intel drivers, but nothing wanted to make ubuntu 14 recognize the displayport. It was working the night before!
finally gave up and went to put some music on. boom! screen turned on. what the hell? unplugged the eighth inch cable again. boom! screen turned off. also, the amplifier turned off and on each time I plugged or unplugged the cable. I'm still 99% baffled here but there's another clue - a buzz on the line that I can audibly hear thru the speakers when this particular sound system is connected, that also changes when I restart the computer.
Note that when I plugged headphones into the eighth inch jack, the screen did not turn on (altho there may have been some signs of life briefly).
So best guess (which is probably very wrong?) is that there's a loose connection somewhere in the laptop, and that the added power from my stereo thru the eighth inch connection (which should be flowing the other direction, but this is an input / output jack) is bridging the loose wire? hence the buzz?
UPDATE 6:30pm same night:
scratch the above theory - new shit has come to light!
when I moved my laptop to the living room and plugged the mini displayport into the projector, everything worked as always - without a sound system being plugged in. So then, being the good scientist that I am, I lugged one of my screens into the living room and plugged it into the displayport, and holy moly, it worked fine, no audio cord plugged in. So it's actually proximity to my crazy stereo system that's causing this issue. Unfortunately I don't know enough about sound systems and electronics to posit a complete theory, altho I bet this is enough for someone to be able to. My general idea now is that the magnetic field cast by the bass amplifier on the floor right next to the monitor is somehow involved.
As before, if you have any ideas, I'd love to hear em.
facepalms: 7.5 (would have been 10 but tempered by the sweet relief of seeing that screen turn on)
Showing posts with label ubuntu. Show all posts
Showing posts with label ubuntu. Show all posts
Tuesday, February 3, 2015
Sunday, July 8, 2012
redis vs rabbit with django celery
if you're planning on putting a django celery app into heavy production use, your message queue matters. At SimpleRelevance we used RabbitMQ for months, since it's probably the most famous of the available options.
It took about 8 seconds to restart out celery workers, but that was fine. In general it was fairly reliable, and the way it routed tasks to different celery workers on different boxes often felt like magic.
However, getting results of a task back using rabbit as a result backend was a different story - it often took minutes, even hanging the box it was on. And these weren't big results either.
So for the record here, we switched to Redis. Not only is restarting about 3X faster, but as a results backend it also wins - no more hanging, and results come back as soon as they're ready. My sysops also tells me it was much easier to install and configure.
boom.
----
update!
actually it turns out redis starts to perform very badly when faced with a deep queue in our production environment. So the optimal setup for us turns out to be RabbitMQ for the queue handling, and Redis for the result backend.
It took about 8 seconds to restart out celery workers, but that was fine. In general it was fairly reliable, and the way it routed tasks to different celery workers on different boxes often felt like magic.
However, getting results of a task back using rabbit as a result backend was a different story - it often took minutes, even hanging the box it was on. And these weren't big results either.
So for the record here, we switched to Redis. Not only is restarting about 3X faster, but as a results backend it also wins - no more hanging, and results come back as soon as they're ready. My sysops also tells me it was much easier to install and configure.
boom.
----
update!
actually it turns out redis starts to perform very badly when faced with a deep queue in our production environment. So the optimal setup for us turns out to be RabbitMQ for the queue handling, and Redis for the result backend.
Wednesday, July 4, 2012
"Error in service module" Ubuntu pam login fail
This was a strange one. One of the newer computers at the lab where I moonlight, running Ubuntu 11.04 (yes, I probably should upgrade to the next LTS, I guess), suddenly stopped logging in. This was preceded by a pink screen and a bunch of errors about the harddrive (so they tell me; I wasn't there. oh, the lives of not IT folk - like living underwater).
So now, whenever they logged in through the GUI, nothing happened - click the user, type the password, straight back to login screen.
So I ctrl alt F1 to TTY1, and log in, and the only error I got was:
"error in service module". Not helpful.
Googling that was helpful in that it started to point the blame at PAM, or Pluggable Authentication Modules, which I now know way too much about.
But anyway I ended up booting into recovery mode which got me past the login, and then overwriting the /etc/init/tty1.conf to skip login even when not in recovery mode following this advice, which allowed me to access the internet and external drives on the machine.
Then I realized that ubuntu logs everything, and I checked /var/log/auth.log, which mentioned a bunch of missing files in /etc/pam.d/ and other fun places. All such fun directories were empty. very strange. So I copied over all of the files from another ubuntu machine into said directories, including a bunch of .so files, and what do you know, login worked. That simple.
Moral of the story - read the logs when something goes wrong that you don't understand. Ubuntu writes a lot of logs, and there's a reason for that. I know I made it seem easy here but it probably took 2-3 hours to do all of the above. facepalms: 4
So now, whenever they logged in through the GUI, nothing happened - click the user, type the password, straight back to login screen.
So I ctrl alt F1 to TTY1, and log in, and the only error I got was:
"error in service module". Not helpful.
Googling that was helpful in that it started to point the blame at PAM, or Pluggable Authentication Modules, which I now know way too much about.
But anyway I ended up booting into recovery mode which got me past the login, and then overwriting the /etc/init/tty1.conf to skip login even when not in recovery mode following this advice, which allowed me to access the internet and external drives on the machine.
Then I realized that ubuntu logs everything, and I checked /var/log/auth.log, which mentioned a bunch of missing files in /etc/pam.d/ and other fun places. All such fun directories were empty. very strange. So I copied over all of the files from another ubuntu machine into said directories, including a bunch of .so files, and what do you know, login worked. That simple.
Moral of the story - read the logs when something goes wrong that you don't understand. Ubuntu writes a lot of logs, and there's a reason for that. I know I made it seem easy here but it probably took 2-3 hours to do all of the above. facepalms: 4
Monday, July 11, 2011
ubuntu problems
so for the last while my wireless card has been acting up _sometimes_, on certain wireless networks but not others. I finally got a clue as to what might be going on: wireless N. It's an N card, but the driver/kernel stuff going on in ubuntu has a known problem with certain wireless cards.
Edited my modprobe.d/options.conf with the line:
options iwlagn 11n_disable=1 11n_disable50=1
and then (hopefully won't have to restart) ran:
sudo rmmod iwlagn
sudo modprobe iwlagn
And that seems to have improved things. So far.
#facepalms: like a lot. Until now. Hopefully.
Edited my modprobe.d/options.conf with the line:
options iwlagn 11n_disable=1 11n_disable50=1
and then (hopefully won't have to restart) ran:
sudo rmmod iwlagn
sudo modprobe iwlagn
And that seems to have improved things. So far.
#facepalms: like a lot. Until now. Hopefully.
Friday, May 6, 2011
Internet exasperations
this one is like a 9 on the facepalm scale. Inexplicably, certain wireless networks (especially dsl and 4g) seem to work, but gradually stop connecting very often, throwing up network errors (could not load variety) on my browser, but then connecting again (quickly, even) after a couple attempts.
I thought I might have just made it better by switching to google's dns servers, but I'm not actually sure it's helped yet.
Note, of course, that I'm using wicd on ubuntu 11 (not network-manager, which was actually catastrophically freezing my computer once in a while).
ideas?
--edit:
Wow, looking back, realized I never shared my solution: turns out certain dell wireless cards have a problem with wireless standard n, but not g. wish I had all the appropriate linkage and help at my fingertips, but if you find this post, that should get you started. I disabled N for my card, and everything is fine (albeit slower than need be). Who knows, mayhap it be fixed by now. I don't remember how I disabled it, and I probably don't need to think about this whole issue anymore.
Friday, April 29, 2011
more ubuntu fights
so I know I thought I fixed my virtualenv and virtualenvwrapper problems recently, but apt-get wasn't letting me install anything! This error:
So it seemed like it had something to do with install-info, whatever that is, but NO - I'd forgotten about some lines in my /etc/environment file that had to do with virtualenv, before I started using .bashrc. took em out, all better.
facepalms: 2
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named virtualenvwrapper.hook_loader
dpkg: error processing install-info (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
install-info
So it seemed like it had something to do with install-info, whatever that is, but NO - I'd forgotten about some lines in my /etc/environment file that had to do with virtualenv, before I started using .bashrc. took em out, all better.
facepalms: 2
Thursday, April 28, 2011
upgrading to ubuntu natty
annoyingness right off the bat. maybe a 7 on the facepalm scale.
1. the login screen allows you to choose between unity and classic, but only after you click the login name to get the password box out. before then, no indication of any possible choices on the bottom bar.
2. loaded up classic, but compiz settings were off.
3. my ATI graphics seem choppy (ouch).
4. virtualenvwrapper acting funky - specifically,
ImportError: No module named virtualenvwrapper.hook_loadereven though things generally seemed to work. Wow, I'm going to have to figure out how to inline code on blogspot here.
Anyways, the problem turned out to be that natty installed python 2.7.1 as default. Nobody warned me! I added the line
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python2.6
To send everybody back to python2.6. Problem solved.
Unity isn't super annoying or buggy yet, but I'll give a shoutout if it becomes so.
Labels:
facepalm,
natty,
python,
ubuntu,
virtualenv,
virtualenvwrapper
Subscribe to:
Posts (Atom)