Vim & Vision

You searched for articles tagged with Linux.

[ #245 ] crontab - escape % (percentage) Permalink

Shell, Linux Added about three weeks ago

crontab command sections like this:

mysqldump db | gzip > $HOME/sql_backup/sqlbackup_`date +%Y%m%d`.sql.gz

... won't work unless you escape your percentages like so:

mysqldump db | gzip > $HOME/sql_backup/sqlbackup_`date +\%Y\%m\%d`.sql.gz

... because (from man 5 crontab):

Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline
characters, and all data after the first % will be sent to the command as standard input.

[ #236 ] Centos (or RH) IPTables Permalink

Linux Added about two months ago

When you try to test your new HTTP server installation on a Centos box, you will find that you get no response. That's because port 80 is firewalled by default. Add this new rule to your tables:

# iptables -I RH-Firewall-1-INPUT 6 -p tcp -m tcp --dport 80 -j ACCEPT
            ^                     ^                       ^       ^
            |            at position 6             the HTTP port  |    
    insert into RH-Firewall-1-INPUT chain                       allow :-)

Then after you've tested this change, make it permanent (otherwise it won't survive a reboot):

# service iptables save

You can check the rulesets at any time with:

# service iptables status

... and remember to do something similar if you have port 443 open for HTTPS...

[ #230 ] apt stuff Permalink

apt, Linux Added less than a year ago

Sometimes I find yourself in a situation where I need to have specific versions of packages installed - perhaps from upstream source errors, untested experimental sources in your sources.list or some kind of local corruption. Here are some apt tricks help (this is not a step-by-step tutorial, just a grab-bag of commands that I sometimes forget about:)

$ apt-show-versions -p vim-common
$ apt-cache policy vim-common
$ sudo apt-get install vim-common=2:7.2.330-1ubuntu3

[ #228 ] Linux - Too many open files Permalink

Linux, Shell Added less than a year ago

If you get the error:

Too many open files

Then your file-max limit is probably set too low. Edit /etc/sysctl.conf to ensure:

fs.file-max = 102400

... (or whatever larger number you want) and then run:

# sysctl -p

to apply the changes.

[ #216 ] OpenVZ VPS and swap space Permalink

Linux, OpenVZ Added less than a year ago

I got a surprise yesterday when I was looking at a VPS. free -m reported no swap space! I didn't know the VPS was an OpenVZ container. These containers will report no swap space from within the VPS - however the whole system still does use swap, it manages it for you.

[ #206 ] Brilliant sysadmin Reference Permalink

Linux, *BSD Added less than a year ago

http://cb.vu/unixtoolbox.xhtml

[ #205 ] Why is GRUB better than LILO? Permalink

Linux Added less than a year ago

Here is another note that could help you in a sysadmin interview.

From http://lwn.net/Articles/89772/:

GRUB has a more powerful, interactive command line interface. LILO, on the other hand, only allows one command with arguments.

LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR). Every time a new operating system or kernel is added to the system, the Stage 1 LILO bootloader has to be manually overwritten, otherwise there is no way to boot the new OS or kernel. This method is more risky than the method used by GRUB because a mis-configured LILO configuration file may leave the system unbootable (a popular way to fix this problem is to boot from Knoppix or another live CD, chroot into the partition with mis-configured lilo.conf and correct the problem). On the other hand, correcting a mis-configured GRUB is comparatively simple as GRUB will default to its command line interface where the user can boot the system manually. This flexibility is probably the main reason why many users nowadays prefer GRUB over LILO.

Unlike LILO, GRUB has a web site. It also has a manual, FAQ, a bug tracker, a developer mailing list and a logo. LILO has none of those.

[ #204 ] Why is swap space important? Permalink

Linux Added less than a year ago

Straight from http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space:

Swapping is necessary for two important reasons. First, when the system requires more memory than is physically available, the kernel swaps out less used pages and gives memory to the current application (process) that needs the memory immediately. Second, a significant number of the pages used by an application during its startup phase may only be used for initialization and then never used again. The system can swap out those pages and free the memory for other applications or even for the disk cache.

Hey - they put it best!

[ #203 ] Perldoc Output Permalink

Perl, Linux Added less than a year ago

If, when you look at the documentation for a core-builtin, like so:

$ perldoc -f system

you get some funny characters in the output (long dashes, 'smart' quotes, etc) - and you wish to remove them (to make copy-pasting of code easier,) then simply:

$ perldoc -tf system

The -t flag avoids any fancy formatting and just outputs plain text.

[ #194 ] Questioning Unix (and Other) File Times Permalink

Shell, Linux Added less than a year ago and last edited less than a year ago

stat displays three times:

atime (last access time)
mtime (last modify time)
ctime (last inode change time)

atime is fairly obvious, where do the others differ? This article tells us that mtime and ctime change when you alter the file's contents - but ctime alone changes when you alter the file's permissions or owner.

What about file creation time? Historically, Unix did not store file creation time.

How do I find the creation time of a file? You can't - it isn't stored anywhere.

Why doesn't old Unix store creation time too? The linked article suggests that creation time is a human concept not a system one - it raises this question: when does file creation time get set when file operations that completely remove, create links to, create copies of, or replace the file in question occur?

To explain that last paragraph with an example, consider these two files:

10:00PM $ echo "hi" > yourfile
10:05PM $ echo "hello" > yourfile

10:00PM $ echo "hi" > myfile
10:05PM $ rm myfile
10:05PM $ echo "hello" > myfile

The two sets of commands both initially create a file at 10:00PM, and at 10:05PM they are both in the same state - but one has been completely removed and re-added. When was it created? Some human interpretation is needed. (See the full email for other shell commands/programs that the poster is concerned as to the interpretation of.)

So does that mean creation time is meaningless and can not be measured? Nope.

More recently certain file systems have started storing file creation time. Consider the UFS2 under FreeBSD.

What about Mac OSX? Yep, the Finder knows about these three file times:

Created
Modified
Last opened

... and if you use stat you will find four values listed: atime, mtime, ctime and birthtime (creation time). Do a man 2 stat and look for the section on st_birthtime which does store the file 'creation time'... if it is available on the current filesystem!

If you are on Windows you will note that NTFS stores:

file times when applications create, access, and write to files.

... so ... I suppose that these filesystems etc have some rules for creation time that the Unix guys couldn't fathom? Let's try things out in the Finder:

% date && echo "hi" > yourfile
Sat  9 Jan 2010 00:39:15 EST
% # I check the Finder and it says creation time is: Today 12:39 AM
% # ... now i wait a minute ...
% date && echo "hello" > yourfile
Sat  9 Jan 2010 00:40:33 EST
% # I check the Finder and it says creation time is still: Today 12:39 AM
% # (but the modified time is 12:40)

% date && echo "hi" > myfile
Sat  9 Jan 2010 00:42:42 EST
% # I check the Finder and it says creation time is: Today 12:42 AM
% rm myfile
% date && echo "hello" > myfile
Sat  9 Jan 2010 00:43:56 EST
% # I check the Finder and it says creation time is: Today 12:43 AM

So, despite the file getting completely blatted both times with new content, only the time when it was rm'ed first caused the Finder to reset its creation time.

I think that makes sense. Consider what happens when you rm:

the directory entry is set to point at 0 instead of the inode it did point at, and the link count for the inode is decremented by one. If the link count has reached 0, and no process has the file open, then the inode itself is marked us unused, and the disk blocks that the file used are returned to the free list.

So, at this point, your data is still there until some other process needs disk blocks and these happen to get reused.

So the inode is still there... with the data... but the inode has been marked as being unused - this is when a file's creation time is lost.

What is my conclusion? I guess I don't know why the old Unix guys thought creation time was immeasurable - perhaps I'm misunderstanding their stance. But I do know that modern filesystems keep the creation time... perhaps I should do a full experiment on all these commands, comparing the file creation times over systems that do store them.

Older Posts ... (Nothing Newer)

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

This is the blog of Brad Willis, a software engineer living in Brisbane.

Links

ChoppingBoard, DaveMisc, Project365, RageQuit