Posts Tagged ‘wc’

Netbooks, bash-scripting and rmmod

Saturday, September 12th, 2009

I recently bought a netbook (Acer Aspire One A531H) which I promptly installed Ubuntu Netbook Remix on. This has worked very well so far, and except for an early problem with wlan (which was fixed after a couple of minutes worth of searching and reading) the only real problem I have had with this little guy is something I experience with all laptops.

The Problem

The sensitive touch-pad of doom. Perhaps I am doing something wrong, I don’t know, but the touch-pads ALWAYS gives me trouble (mostly by “conveniently” moving the cursor to another part of the text while I am writing something).

I tried a workaround, using syndaemon with the flag -d, to have the touch-pad temporarily disabled while using the keyboard, moving that into a script and configure that script to run at startup. It is a nice idea, but it re-enables the touch-pad too quickly again, so while cutting the number of incidents in more than half, I still wasn’t satisfied.

On my regular laptop, which I always connect an external trackball to, I have permanently disabled the touch-pad (sudo rmmod psmouse at upstart) but permanently disabling it on the netbook wouldn’t work either, since for some tasks (like web-surfing, no I haven’t gotten around to learning the vimperator add-on just yet) are quite a lot easier with a mouse than without it.

The Solution

So what I really wanted was a convenient way of quickly enabling and disabling the touch-pad, when I needed to.

Reusing old knowledge about how to manually add shortcuts to metacity, all I had to do was to create a script which ascertained the status of the psmouse module (loaded or not) and upon that, either removed or loaded it.

To get the state of a module Foo, one can use lsmod | grep Foo, which in this case leads to lsmod | grep psmouse. This will either yield nothing (module not loaded) or a line (module loaded).

We can improve on this a bit, making sure we always get some kind of value returned, something like lsmod | grep Foo | wc -l. Since the last command in the chain now counts the number of lines that was returned from grep, we now either get 0 or 1 returned.

So there I was, thinking I am done, having entered the gconf-editor, pointed the script to command_2 (apps > metacity > keybinding_commands) and assigned a key-binding (<Control><Alt>t) to run_command_2 (apps > metacity > global_keybindings). Life was playing, all was well. Except for the fact that hitting that key combination did absolutely nothing to shut down the touch-pad.

Which was odd, since running the script worked. The individual commands to disable and enable the touch-pad (sudo rmmod psmouse and sudo modprobe psmouse, respectively) worked flawlessly… so why didn’t this work?

Then it hit me. Running either of those commands from the command-line, would result in it prompting me for my password, something a poor script without any ability to accept input from stdin can’t do. It couldn’t even tell me about it since there was no stdout for it to use either.

gksudo to the rescue. Since gksudo pushes up a graphical password prompt, the script could once more ask me for a password, and I could again supply it. And now it works nicely :D

In closing, the script:

#!/bin/sh

if [ $(lsmod | grep psmouse | wc -l) -eq 0 ]
then
    gksudo modprobe psmouse
else
    gksudo rmmod psmouse
fi
exit 0

Strange things you find out about your system half past six on a Thursday morning

Thursday, May 28th, 2009

Woke up somewhere around 0500 hours, heartburn… couldn’t go back to sleep so landed in front of the computer. Read an article (in Swedish) at idg.se about EU and the Telecoms-package nonsense. Apparently cookies are still unsafe… uh-huh.

There was a comment to that article about Local_Shared_Objects which caught my eye, and after having examined my ~/.macromedia-directory I could conclude that Flash stores its “cookies” there. To my surprise they took up quite some space, so I removed those domain-directories which lay inside the “random-id” directory.

For some reason, while Googling in order to ascertain whether it would be safe to remove the directories (I found nothing that indicated it would be safe, nor that it wouldn’t be safe), I found a post about an Ubuntu user who needed help cleaning up his “filled-to-the-brim” partition, and asking what he could remove.

Some responses told him to set his eye on /var/log among other places, and realizing that it was quite some time since I did that myself, I too headed for /var/log

And I started chopping away at the gzipped archive files there (to be honest, it was on fell “sudo rm *.gz” swoop, but who is counting?)

du -sh . indicated there was still some  309 Mb of “stuff” in /var/log (down from 312 Mb or something) so I was not impressed. What was taking up all that space?

Digging a little further I finally zeroed in on the guilty party. /var/log/acpid occupying 297 Mb of my harddrive. Running tail on that file a couple of times made me realize that it made entries into that log more than once every second…

So just to ensure that this wasn’t all just some stupid me poking around the system, spur of activity logging, I told grep to find all lines containing the string “May 27″ (which now in retrospect would match previous years May 27 as well, which means I could have been greping lines as far back as May 2007, this is a Feisty-box, although I am pretty sure that it took me a while after Feisty was released for me to give up Edgy, all in all, I don’t think I had Feisty installed by May 27th 2007, so two years worth of logs) and counted the lines of that output  grep ‘May 27′ .acpid | wc -l, which returned around 1.2 million hits.

I assume an equal distribution of entries per year, so 600.000 entries made yesterday. 600000 (log entries) / 86400 (seconds in a day) is almost 7 writes a second!

This was clearly not acceptable. I hit Google again, what would be the best way to kill all acpi logging? The launchpad bug report I found indicates that the bug is closed, having been fixed, which is good, once I upgrade when my harddrive goes to… whatever place harddrives go when they have served their time, this will not come back to haunt me.

But Feisty isn’t being bug fixed anymore, so how would I do it?

By adding the arguments “-l /dev/null” to whatever script that start the acpi daemon (acpid). I.e. /etc/init.d/acpid

Again, solutions offered in the forums seemed to target a different version (probably older) than Feisty, as I could not find a line containing $ACPID_BIN = /sbin/acpid

I did however find out that my version used start-stop-daemon to umm… start the daemon. Which takes the flags –exec [arg] and -c [args] (arg being the path to a daemon to start, and args being the arguments to pass to the daemon)

Very nice!

start-stop-daemon –start –quiet –exec /usr/sbin/acpid — -c /etc/acpi/events $OPTIONS

becomes

start-stop-daemon –start –quiet –exec /usr/sbin/acpid — -c /etc/acpi/events $OPTIONS -l /dev/null

I stopped and restarted the the acpid (since the restart sequence looked a little different and I didn’t want to muck with that, I know my own illiteracy and incompetence ;)), killed off the acpid log, and my /var/log is now down to 12 Mb in size all in all.

Reading further in the bug report it would seem that this little acpid “I’m gonna log the shit out of you” behaviour is, to some extent, connected to the laptop harddrive-killing bug. Thankfully my harddrive seem to have survived that bug quite well (probably due to my early hacking of /etc/hdparm.conf as per this page).

Forkbombs

Tuesday, March 3rd, 2009

I’ve been going through my bookmarks and trying to organize them (that stumbleupon fed the firefox bookmarks every time I upvoted something hasn’t helped), and among the bookmarks I found this little gem, about how you can thwart forkbombs before they are able to do any serious damage.

In /etc/security/ there is a file called limits.conf, which can be made to control a whole host of different settings. With the hardware of today I find a hard kill limit of 150 processes to be on the cheap side (on the other hand, executing ps aux | wc -l on my system reveals that right now, 117 processes are running, 32 of which are owned by “me”, 71 by root and 16 by various other system users (cupsys, ntp, mysql etc).

On a side note, I love pipes and grep.

$ ps aux | grep root | wc -l
71
$ ps aux | grep patrik | wc -l
32
$ ps aux | grep -v patrik | grep -v root | wc -l
16

It might not be necessary to allow more than 150 processes, but on the other hand I would find it irritating hitting this limit (although hitting it would probably indicate that I have to much crap running at the same time) and the real use for this limit on a single-user system would most likely be to ward off the effects of unwittingly doing something stupid (executing a forkbomb is stupid), so one can probably afford to raise this limit a bit higher, to 200-300 processes.

UPDATE:

After having forwarded tuss’ brilliant idea of having hesa incorporate this little tip in his C class (preferably before teaching about the fork(); function), hesa shot it down *mumble*platform specific solution*mumble*. This is of course true, and should serve as just another good reason to switch from Windows ;D

In any case, it got me thinking. Ubuntu, which inherits from Debian, seem to be identical in the important things. /etc/security/limits.conf does indeed seem to exist in Debian as well. And Red Hat, so presumably in Fedora as well.

Slackware however, seem to store this data in the file “limits” directly under /etc/ (i.e. /etc/limits). It is by no means an exhaustive search, but Googling for “[your_favorite_distro]” and “limits.conf” or “limits” or “limiting processes” should hopefully reward you.

UPDATE2:

I spell like a douche…