Truecrypt is already running

Sometimes, when trying to start up Truecrypt, a message will come up saying “Truecrypt is already running”. This may happen when the previous Truecrypt session was not closed properly.

To resolve the problem type at a terminal prompt:

$ rm ~/.Truecrypt-lock-USERNAME

where USERNAME is your username.

Posted in Linux | Tagged , , | Leave a comment

Using Anacron in Ubuntu for Periodic Jobs

Anacron is a very handy utility to run scripts in regular periods in machines that are not turned on 24/7. It is actually very simple to use, but I found that there were very few resources describing how to actually set up an Anacron job.

Setting up an anacron job in Ubuntu is as simple as creating a script, name it correctly and assign it the right permissions, then deciding whether it should run hourly, daily, weekly or monthly and then drop it in the right location. Anacron will then run the script at the appropriate frequency.

Let’s explain that in more detail, firstly, the anacron scripts live in the following directories:


When you place a script inside one of those directories, it will run at the specified frequency.

A few gotchas to keep in mind are:

1, Make sure that the script does not contain dots in the name, i.e. do not add an extension. The name of the script can only contain letter, numbers, underscores and hyphens.

2. Apply the correct permissions; the script must be executable and owned by root. You can just check the permissions of existing scripts to know what permissions to use:

$ ls -l /etc/cron.daily
total 72
-rwxr-xr-x 1 root root 311 Jun 20 2010 0anacron
-rwxr-xr-x 1 root root 633 Feb 14 2012 apache2
-rwxr-xr-x 1 root root 219 Apr 10 2012 apport
-rwxr-xr-x 1 root root 15399 Mar 13 2013 apt
-rwxr-xr-x 1 root root 314 Aug 8 2011 aptitude

3. If your anacron jobs are not running and you are using a laptop, make sure that the laptop is connected to the mains; as a default in Ubuntu Anacron doesn’t run when the laptop is on battery.

4. To find out when each script is scheduled to run:

$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

This shows that the hourly scripts run at 17 minutes of each hour, the daily scripts run at 6:25am, the weekly scripts run on Sunday and the monthly scripts run on the first of each month at 6:52am.

5. The above schedules are really only the earliest time the script will run. If the machine wasn’t powered on when the script was due to run; it will run at the next opportunity based on the following:

$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# These replace cron's entries
1 5 cron.daily nice run-parts --report /etc/cron.daily
7 10 cron.weekly nice run-parts --report /etc/cron.weekly
@monthly 15 cron.monthly nice run-parts --report /etc/cron.monthly

The first column indicates the frequency in days and the second specifies a delay for how many minutes should anacron wait to start running the scripts after the machine starts. So, in the above example, the anacron tab specifies that the daily scripts will run once a day and will wait 5 minutes before start running. The weekly scripts will wait 10 minutes before start running and the monthly ones will wait 15 minutes.

Posted in Linux | Tagged , , | Leave a comment

Quick guide to cron in Ubuntu 12.04

Here are some basic concepts on how to set cron jobs in Ubuntu 12.04.

1. The crontab

The crontab is the file that contain entries for each scheduled job, more information at Ubuntu’s Cron How To.

In order to edit the current user’s crontab use:

$ crontab -e

To edit the root’s crontab:

$ sudo crontab -e

In this case we will edit the user’s crontab. To set up a quick test, add the following line at the end of the crontab (as a safety meassure, make sure that there is an empty line at the end of the crontab, as explained in reasons why crontab doesn’t work):

* * * * * touch /tmp/test.txt

This should create an empty file text.txt in your /tmp directory every minute.

2. Cron logs

If things don’t work, there are two good ways to help identify the problem. First, make sure that logging for cron is enabled. In Ubuntu 12.04 you need to make sure the following line is uncommented in /etc/rsyslog.d/50-default.conf.

cron.*      /var/log/cron.log

This sends all cron logging to /var/log/cron.log, which you can then inspect to ensure that you cron is running:

$ tail -f /var/log/cron.log

For this to take effect, you need to restart the syslog service:

$ sudo service rsyslog restart

3. Running a bash script from cron

If this works, we can now create a simple test bash script. A good place to put user scripts is /usr/local/bin, scripts meant to be run as root can be placed in /usr/local/sbin:

$ vim /usr/local/bin/

Add the following to your file:

#! /usr/bin/env bash
touch /tmp/testing2.txt

Modify your crontab entry:

$ crontab -e

* * * * * /usr/local/bin/

Did that work?

$ ls /tmp

If not, try making your script executable and ensure that the owner and group of the script are correct. Assuming that the user and user group are toto:

$ ls -l /usr/local/bin/
-rw-r--r-- 1 root root 45 Sep 28 12:25 /usr/local/bin/

$ sudo chmod u+x /usr/local/bin/ && sudo chgrp toto /usr/local/bin/ && sudo chown toto /usr/local/bin/

$ ls -l /usr/local/bin/
-rw-r--r-- 1 toto toto 45 Sep 28 12:27 /usr/local/bin/

If you need further debugging (your crontab is running and it is calling your script but nothing seems to happen), you can send the output of your script to a temp file. Make sure your crontab entry looks like this:

* * * * * /usr/local/bin/ >/tmp/cron_output.txt 2>&1

Later, if you wish, your script’s output can be discarded:

* * * * * /usr/local/bin/ >/dev/null 2>&1

This, hopefully, should be enough to get you going with a basic cron setup.

Posted in Linux | Tagged , , | Leave a comment

Adding line numbers in Vim

In order to add line numbers there are seveal options:

Add line numbers (applies to the current session only)

:set number


:set nu

To turn it off there are three ways: (only applies to the current session)

:set nonumber

:set nonu

:set nu!

To enable line numbers on start up, add the following to .vimrc

set number


set nu

Having the line numbers displayed is extremely useful with used in conjunction with the command to move to a given line number, for example to move to line 25:


TIP: to find out where vim will look for the .vimrc file, open vim and in command mode type:


In the output message there will be something like:

system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"

In this case the user vimrc will be $HOME/.vimrc

Posted in Linux | Tagged , | Leave a comment

Tried and tested processes and techniques for front end web development

Over the years of developing and creating different websites I have come up with my own tried and tested method for doing web development. I would like to describe here my method for developing front end code in particular. All of these techniques will probably be familiar to seasoned web developers as they have proven their worth over the years. In this entry I will only give a general outline of my methodology, leaving the task to go into the finer detail of each technique for other articles.

The first principle I apply to web development is progressive enhancement which, in simple words, implies developing in layers, beginning with the HTML layer, which represents the content, and progressively moving to CSS to add presentation and then to JavaScript to add behaviour to the content.

The best way to go about this is to construct semantic HTML based on the content for your website. This clearly implies that you first need to have either the actual content for your website or a very accurate idea of what this will be before you start writing a line of code. This is mainly for two reasons: the first is that, once you know the actual content of your website, it is then easier to think which HTML element provides the better semantic representation of your content. The second reason is that, by starting with the HTML first, you set a solid foundation for the subsequent layers and avoid putting design and behaviour considerations before content. Remember: in the web, content is king. Semantic HTML and progressive enhancement are the next two principles I apply to web development.

After having a solid base of HTML I can then move on to thinking about a few, two or three maybe, different layouts and then, based on the chosen one, adding styles to the site or web page. A technique that helps me tremendously in this and the next phase (adding behaviour) is that of coding a little and testing often; what I mean by this is quite simple actually. What I do when I am adding CSS is to add a few styles and then test the changes in all the browsers that I have previously defined as required to be supported. This lets me iron out any discrepancies and browser bugs early during development instead of having to deal with a finished design that totally breaks in one or more browsers. I find this particularly useful for debugging problems with Internet Explorer; as a result of coding a little and testing often I can identify IE bugs very early and address them as they arise. I make use of conditional comments for IE in order to fix its bugs and I have found that, by using the technique mentioned above, I usually end up with very few lines of IE specific code that address specific bugs in a very specific way. This in turn keeps my main CSS files clean and hack free and it keeps the IE specific code isolated so that it can easily be modified or removed in the future if the particular IE version doesn’t need to be supported any longer. When using CSS3 properties I go with the commonly accepted technique of using vendor prefixes.

Finally, I add the behaviour layer; the JavaScript. This adds enhancements to the page or site so that its usability is improved but in no way is the JavaScript used to provide functionality that is both fundamental to using the site and unavailable in circumstances when JavaScript is either partially or no supported at all. This is where having a solid HTML foundation also shows its worth since all enhanced JavaScript functionality, when vital to accomplish the core tasks of the site, will have its equivalent in the plain HTML version. This is often easier said than done and each particular case offers its own challenges and compromises that sometimes have to be made in order to maintain usability and accessibility, but the results are worth the effort since an accessible website is usually more usable for all visitors and can also rank better in search engines.

I have a set of preferred tools when accomplishing all the tasks mentioned above. One of the most useful is Firebug, a very well known add-on to Firefox that makes many development tasks a breeze and which has set the standards for similar tools that most modern browsers now include as default in their configuration. So, along Firebug, I also use the IE developer toolbar, Chrome’s and Safari’s developer tools, and Opera’s Dargonfly since these are the browsers that I support in most of my projects. On top of that, I use Virtual PC with images for the other IE versions different to the one I have in my development PC and, of course, any useful text editor. These days I use Komodo Edit, but I have also used Crimson Editor, Notepad++, Eclipse and plain Notepad. It also helps to have a local web server (Apache is a common choice) to run my pages from there.

The above steps summarise my methodology for developing front end. I have found that, by following the simple principles of progressive enhancement, semantic HTML, content before presentation and behaviour, and code little and test often for cross-browser compatibility; my task of creating cross-browser, accessible and usable websites becomes a lot simpler. I keep learning new techniques all the time and I try to incorporate them to this process in order to further enhance my skills. I hope that this short writing is found useful by readers trying to understand the process of creating front end code for the web; my aim is to expand each of the mentioned techniques and tools in future entries.

Posted in CSS, HTML, JavaScript | Tagged , , | Leave a comment