Computerworld: California May Join Rush of States Toward ODF

A California legislator last Friday introduced a bill that would mandate the use of open, XML-based document file formats by the state government starting next January…
Complete story.

Killing misbehaving programs and processes

I’d love to say it doesn’t happen on Linux, but very rarely it does. I can say it happens less often than on Windows, though. What am I talking about? Programs and processes misbehaving - locking up, stopping working and generally causing a problem.

The problem on Windows is that if this happens, there’s no sure fire way to just nuke the offending app from your running processes. Yes, you can use Task Manager and close the process, but if that doesn’t work, well… (bad memories here).

On Linux, if this situation does occur, you have a couple of wonderful programs called kill and killall that are invaluable for killing things when they go wrong (saves many a restart of the whole system).

This is going to be quite a quick tutorial, partly because the subject matter doesn’t take that much time to cover and partly because I’m starting to get quite a lot of work I have to do, which means I’m going have to be a bit brief. Anyway, onto the tutorial…

Your first port of call is to try running kill normally on the offending process. In this example, we’ll presume that Firefox has stopped behaving.

First of all, you need to get the process ID number of the process. In this case, we’re looking for firefox-bin. So we need to launch a terminal (it’s that time again) and do the following:

$ ps aux | grep -i firefox-bin

First, let’s look at what this is doing. ps aux gets us a list of processes, then we are taking the output of that and running it through grep (it’s a way of finding every line containing something). We ask grep to be case-insensitive with -i and we ask it to display all lines containing firefox-bin.

You will probably get multiple lines here. Pick out the one without any reference to run-mozilla.sh (and not the one saying grep) and look to the left. The process ID number is the number there. With any other program, the name of the process is generally the name of the program (without the -bin). There are some exceptions, unfortunately.

Armed with this information, we can now kill Firefox. If you do this now and you’re running Firefox reading this, Firefox will close without warning!

Now simply run kill and tell it the process ID we found out (replace nnnn with the number we discovered earlier.

$ kill nnnn

Bang! The offending program should be dead beyond recognition now and your problem will hopefully be alleviated. Of course, on some occasions nothing happens when you try and kill something.

Basically, kill isn’t actually killing the process at this stage. It’s asking it nicely - “x, I would very much appreciate it if you would close down… like now.”. When a program is being particularly stubborn, this won’t work.

In these cases, you set kill from stun, to … sorry. Instead of asking nicely, we simply forcibly remove it from running on the machine. A word of warning - killing things in this way doesn’t give them a chance to clean up what they’re doing and you may end up with corrupted files and memory leaks in really bad cases. Use this as a last resort only.

$ kill -9 nnnn

The -9 is the difference here and does the job in 99.5% of cases.

But throughout all of this, there’s an easier way. So why have I shown you the hard way first? Because I thought it might be worth having a basic understanding of processes first. Plus, the method I’m about to show you sometimes kills more than you want it to.

killall allows you to specify a process name (e.g. firefox-bin or konqueror) instead of an ID. The difference is it will perform the killing on any process with that name, not just the specific one that might be going wrong.

It’s the same deal here:

$ killall name-of-process

And for those heavy-duty situations:

$ killall -9 name-of-process

That’s it!

Easy, simple and a heck of a lot better than getting stressed with Windows Task Manager which doesn’t give you (correct me if I’m wrong) an option to actually wipe the process off the face of the earth, short of hitting the power real fast, which of course would kill everything and probably damage your hard drive.

Wow, that was easy wasn’t it?

And as with all my tutorials, if you’ve got any suggestions, had a few problems or you genuinely found this useful, I’d love it if you’d drop a comment on this post, it makes writing these so worthwhile!

(fosswire.com)

How to increase your linux system loading speed

Linux can be run on various run level, for run level 0 is shutdown, and run level 6 is restart and usually run level 1 is single user linux.

By default, fedora and red hat will running run level 5 and Ubuntu is running 2. By knowing what run level of your linux distro init, you can further tweak your system by stopping wanted services. The easiest way is to manipulate the symlinks in /etc/rcX.d, where ‘X’ is your default run level. For the case of Ubuntu, it is /etc/rc2.d.

Thats why to shutdown my system, I can do

sudo init 0

In /etc/rcX.d, it contains symlinks looks as bellow:

K19hplip            S11klogd          S20powernowd                 S91apache2 K20festival
S13gdm              S20rsync          S98noip2 K20nvidia-kernel    S19cupsys
S20samba            S98usplash        K20wifi-radar                S19mysql
S20ssh              S99acpi-support 

They are all symlinks, the real scripts contain in /etc/init.d. S indicate the service will be loaded during initialization of your system, and K indicate Kill, means stop service. So, the simple hack is changing the file name from S to K

Let say I would like to turn off apache from loaded during startup, I do

sudo mv {S,K}91apache2

Turn it on back,

sudo mv {K,S}91apache2

Okay, we cannot assume we are running on run level 2 or 5. It must be a way to know what run level we are running. Check out /etc/inittab

You will find a line show as bellow, which indicate that your default run level is 2.

id:2:initdefault:

But, Eh! WTF, why Ubuntu Edgy do not have inittab?!! How am I suppose to know what run level am I running now?

Ubuntu Edgy abandon the convention way of manipulate run level but replace with upstart.

To know what is your previous and current run level if your system uses upstart, type

runlevel

The output:

N 2

First column indicate the previous run level, N means None. Follow by current run level, which is 2.

(linux.byexamples.com)

Pages (13): « First ... « 4 5 6 [7] 8 9 10 » ... Last »