^C doesn’t kill processes, SIGINT does

On the LUV mailing list recently, the perils of tty handling when booting with “init=/bin/bash” came up, and somebody asked why running ‘ping’ (without remembering to run stty or openvt first) will result in you having to reboot.

i.e. “why doesn’t ^C work in emergency mode”?

I wrote a fairly detailed, but comprehensible to a novice, answer and a friend suggested i should have written it as a blog post – which was the point of me setting up a blog in the first place.

So here’s a slightly edited version of it:

> Couldn’t you just open another console, run “top” and find the PID for
> ping and kill it? Or ps aux |grep ping and kill it? Is a reboot the
> only way to kill a ping where ^C is not available?

there’s nothing special about ^C except that by long convention it is mapped to the interrupt signal aka intr aka SIGINT. So, ^C itself doesn’t kill a program, the fact that it generates an interrupt signal does.

If you’ve rebooted for emergency maintenance (e.g. “init=/bin/bash” on the LILO or GRUB command line) then all you get is ONE instance of /bin/bash. Nothing else is running and nothing else has been run (because you’ve overriden the usual init with /bin/bash). No setup has been done on the terminal, and no other virtual terminals have been opened. The emergency environment is minimal (and deliberately so – you asked for it, you got it). It’s up to you to do whatever is needed to set up the environment so that you can do the required maintenance/repair work.

So if you run ping *before* remembering to set up the terminal (‘stty sane’) then ^C doesn’t work because ^C doesn’t generate SIGINT so there’s no way of telling ping to quit, and if you haven’t opened another virtual terminal with openvt (aka “open” – it got renamed some time ago) then there is no other shell available to run top or ps or kill.

BTW, it’s not just ping. You’ll see the same problem in the same environment with ANY program that runs continuously until it gets a signal to terminate it. ping’s just the most obvious and common example.

Most programs, especially simple programs like ping, don’t have a ^C handler. They don’t need one. They have a signal handler which, amongst other things, handles SIGINT however it’s generated – it can be generated by pressing ^C in a normal tty environment, or by sending the program a SIGINT (e.g. “kill -2″).

That, BTW, is a core difference between a SIGTERM (just plain ‘kill’ or ‘kill -15′) and SIGKILL (‘kill -9′).

SIGTERM is usually handled by the program by setting up a signal handler for it, and it voluntarily terminates when it receives the signal (usually cleaning up, closing files, etc before it does so). If the program hasn’t set up a handler for SIGTERM then the default action is to just terminate. A program can set up a handler which does nothing on SIGTERM, which effectively just ignores the signal.

SIGKILL is handled by the kernel and it just kills the process immediately – it can not be blocked or intercepted by the program.

(By common convention, SIGHUP or ‘kill -1′ tells a long running daemon process to just reload it’s config files. It’s also generated when the tty that the program is running on is terminated – e.g. you log out or the modem hangs up or the ssh session dies, hence the name “HUP” aka “HANGUP”. That’s why you need to use something like nohup or screen if you want a program to continue running after you log out)

In a way, ‘kill’ is a bit of a misnomer. It’s actually a generic tool for sending signals to running processes, but the default action for most of those signals is to terminate the program. Here’s a list of the signals which can be sent.

$ kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL
 5) SIGTRAP	 6) SIGABRT	 7) SIGBUS	 8) SIGFPE
 9) SIGKILL	10) SIGUSR1	11) SIGSEGV	12) SIGUSR2
13) SIGPIPE	14) SIGALRM	15) SIGTERM	16) SIGSTKFLT
17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU
25) SIGXFSZ	26) SIGVTALRM	27) SIGPROF	28) SIGWINCH
29) SIGIO	30) SIGPWR	31) SIGSYS	34) SIGRTMIN
35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3	38) SIGRTMIN+4
39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12
47) SIGRTMIN+13	48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14
51) SIGRTMAX-13	52) SIGRTMAX-12	53) SIGRTMAX-11	54) SIGRTMAX-10
55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7	58) SIGRTMAX-6
59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

See the man pages for init(8), kill(1), and especially signal(7) for more info on this topic.

a

Almost every web site i visit these days seems to have a style sheet written by some idiot who thinks “if it looks good on my screen using my eyes then it’s perfect for everyone”.

WRONG

Specifying widths in pixels is NOT for text. It’s for images, you morons.

For one thing, small fonts suck if you have a large, high-resolution monitor. or if you have bad eyesight. or if you’re getting older (I was helping my mother find a house to buy a few days ago and the real-estate web site we were searching was basically unreadable for her – she could see the house pictures but I had to read out the text, and even I found that difficult because of the tiny font).

For another thing, if you have a wide-screen monitor and a browser window to suit it, then a fixed-width column of 560 pixels or so looks really bloody stupid in the middle of a huge expanse of empty white space, even with another column or two at the sides for meta-stuff.

There are tools, like the Stylish and NoSquint plugins for Firefox/Iceweasel that help you make a site more readable, regardless of what the so-called “designer” perpetrated. But, cool as those tools are, they just should not be necessary. And I, as a user of the web site, shouldn’t have to spend 5, 10, 20, or more minutes reading and understanding their style sheet so i can hack up a tweak for it JUST TO MAKE IT READABLE.

They’re the designers, that’s their job, not mine. That’s what they’re (presumably) getting paid for – and yes, the commercial/professional web sites tend to be far worse offenders than the amateur sites.

Web designers should have enough bloody sense to make their sites look good in ANY font size, at ANY window width. It’s not hard. In fact, it’s easier and much less work than hard-coding pixel sizes.

I’m not a web designer, nor am I anything remotely like an expert in CSS or style sheets. I’m a systems geek. But if I can figure this stuff out, when it’s not even my job to do so and i have no intrinsic interest in the subject, then why the hell can’t they? Don’t they take pride in their work? Don’t they care that visitors to their web sites will think they’re clueless morons for perpetrating yet another squint-eyed monstrosity on the web? Don’t their employers give a damn?

To summarise:

1. text widths in style sheets should be specified in relative units such as percentage or ‘em’ units.
2. font sizes should be specified in ‘em’ units, if you must specify them at all.
3. all other non-image/embedded-media sizes should also be specified in ‘em’ units.

Doing those three simple things will ensure that your web site looks good to all visitors, no matter what size screen/window they have, and no matter what font-size they have to use to be able to read it.

end-of-rant.

PS: My own hacked-up theme/style-sheet for this blog is far from perfect….but I did take the time to make sure all the widths and font-sizes were relative. If there are any CSS bugs feel free to point them out and i’ll fix them ASAP…like I said, I’m far from an expert in CSS.

a

IMO, there are much better ways of doing it. Specifically, generating config fragments for each virtual host.

I wrote such a system years ago, and have always thought “I should package it up for debian”. There’s a moderate amount of work involved in doing so, and probably an even larger amount of support work afterwards. Worst of all, I’d have to write – or con someone else into writing – documentation for it (it’s easy enough to use that you can be SHOWN how to use it in 10 minutes, but that isn’t good enough for a distributed package).

I guess the point of this blog post is to find out if there’s sufficient interest to make it worth the effort. Feel free to comment or email me about it.

If anyone wants to look at the code, i can tar it up easily enough, and even write some simple/minimalist instructions.

anyway, here’s (a slightly edited version of) what i posted to LUV-main:

Preamble

I looked into apache’s mod_vhost stuff years ago, but IMO it’s just too inflexible and limited to be of much use. It’s fine if ALL your vhosts are identical…but not if you need different settings on some or all of them. As soon as you need a custom setting for one vhost, you have to step outside mod_vhost_alias and roll-your-own anyway. which means you now have two different methods of configuring your vhosts.

Instead, I’ve used my own vhosting system for years (long before mod_vhost), on dozens of servers…the largest of which had over 500 vhosts on it – the biggest problem was the enormous number of file handles the apache processes needed for log files.

After tweaking the kernel file-max etc limits, it actually worked without problem but I always intended to rewrite that bit of it to use a log splitter daemon, perhaps vlogger or similar. Unfortunately, I a) left that job before I had time to implement it, and b) never did figure out a good way to handle the error logs because apache doesn’t prefix the vhost name to ErrorLog output like it does for CustomLog outout (best compromise was to just have one combined error log rather than one per vhost….most web programmers/website operators never look at the error logs anyway. Personally, I find it invaluable, most people don’t even seem to think of looking at it)

Synopsis of Operation

1. Creating a new vhost is a 3-step operation:

1. create a user (with adduser), optionally with a postgres or mysql account of the same name.
2. edit /etc/virtuals/virtual-hosts.conf, copy/paste/edit one line
3. run “make”

In step 2, hardly anything needs to be changed from one vhost to another – in the most common case, just the account’s login name, and the domain name. There are a number of different “flags” that can be set for each vhost in this file – ssl, cgi, mason, htdig, webcheck, aliases, group, samba, canonify (use mod_rewrite to redirect back to the site’s canonical name), and more.

The Makefile runs perl scripts to generate the apache config fragment (and other config fragments – e.g. for htdig and samba), add/remove any IP addresses if needed (usually not, with name-based vhosts), set up the home directory structure, copy in any sample files (e.g. html forms and images for htdig), and reloads apache. It also checks in any changes to svn (or RCS. easily modified to use other revision control systems).

On machines which are part of a load-balanced setup, it even ssh-es into other machines in the array, runs “svn update” and “make” to ensure that the vhost is operational on the other machines too.

Finally, it concatenates all the active config fragments into one large file because apache reloads a LOT faster if it doesn’t have to load hundreds of little config files.

2. Removing a vhost is as simple as editing virtual-hosts.conf and commenting out or deleting the line, then running make again.

virtual-hosts.conf

The virtual-hosts.conf file is extremely useful. It gives me a single authoritative source of all the relevant details about EVERY vhost running on a machine. These details can be used by other scripts (e.g. cron jobs to run webalizer, analog, htdig indexing, webcheck, etc; cgi scripts to display a list of vhosts on the machine with clickable links, and more).

This single config file makes the whole system easily extensible: write a new script to parse the config file, and loop through each entry, performing some relevant operation. e.g. run webalizer for every vhost, dumping the output under ~/public_html/LOGS/ (with optional .htaccess file to control access). Adding optional generation of samba shares for each vhost was quite easy.

In theory, it wouldn’t be hard to put a GUI or web front-end on to it. Oddly enough, i’ve never bothered. And I’m not inclined to bother now (but wouldn’t object if anyone else did)

Database? no, thanks

I’ve occasionally thought about putting this config data into a database, but the benefits just aren’t anywhere near good enough to outweigh vi and all the benefits of text file configuration (especially comments!)

Packaging?

And, of course, one of these days, i should package it all up for debian. I’ve been saying that for years, and just haven’t got around to it. It wouldn’t take a huge amount of work to do so, there are only a few small things i need to do to automate the installation, things that i just do by hand in a few minutes when installing on a new box.

Before packaging it, I also want to automate the adduser part of the process, as well as creation of postgres or mysql accounts. Most importantly, I ought to separate the code from the templates in the config fragment generator scripts, so that the local sysadmin can edit them without having to edit the scripts….OK, all up not a tiny job but not particularly big either….just big enough to be ignored on my TODO list for years.

I’d definitely have to change the config file format from the current one-line (colon separated fields) to using a .ini style file. I’ve wanted to do that for a while but have inertially-resisted it so far because the one-line format is so convenient…unfortunately, I’ve added so many flags and features over the years that it’s seriously ugly – probably scary to someone who doesn’t know it already (i.e. anyone outside of the set of “me + a handful of other people”). I estimate this would take about a days worth of hacking

I’d also take the opportunity to clean up some of the cruft :-)

Essential Design Criteria

BTW, one crucial design criteria for my system is that it should *NEVER* under any circumstances overwrite any hand-edited changes.

This is implemented in a number of ways. First, it takes an md5sum of each vhost’s config fragment when it generates it. If/when the script is run again, it only re-generates the config fragment if the md5sum hasn’t changed. If it has changed, it generates the updated fragment as “.new” for manual merging if required. Secondly, when generating conf fragments it looks for specially named files in a directory for extra stuff to add before the <VirtualHost> line, between the <VirtualHost>…</VirtualHost> lines, and/or after the </VirtualHost> line. This is to provide another location to put custom changes for each vhost while still retaining the ability to have improvements/new features to the script automatically applied to existing vhosts.

The reason for this is that I utterly loathe and despise allegedly “easy” configuration tools that blow away custom hand-edited changes. I hate them so much that this was THE major incentive for developing my own vhosting system.

In Use

I’ve been using my system for over 10 years now. It grew out of earlier bits and pieces, but the current incarnation has been working since 1999, with the occasional new feature or update (e.g. to add support for apache2 as well as apache1, and minor changes to adapt to changes in debian’s apache packaging).

There are also a handful of ISPs and several small businesses around Australia running it because they’ve hired me to set up their web servers.

Finally…

My vhosting system isn’t a system for people who are scared of or dislike command-lines or text-file configs. It’s a system for people who love them, but want an easy way to automate a dull, repetitive task. Such automation is easy for CLI tools, and next to impossible for web/GUI tools.

a

That’s actually the wrong question.

The right question is ‘Why is /var/cache/apt/archives even relevant on a machine with a full mirror of debian?’

/etc/apt/sources.list has always supported file:/ URLs. for example, sources.list on my local debian mirror looks like this:

deb file:/home/ftp/debian unstable main contrib non-free
deb file:/home/ftp/debian-multimedia/ unstable main

With a file URL, apt-get doesn’t need to download any packages, and thus doesn’t need to cache anything in /var/cache/apt/archives. No need to keep it empty, it just is empty.

In a related post, Andrew Pollock suggests adding DPkg::Post-Invoke { “apt-get clean”; }; to /etc/apt/apt.conf.

That would be fine if you ONLY ever ran “apt-get update ; apt-get dist-upgrade”.

It’s not fine if you run “apt-get -d” to download packages first, then install a few packages with “apt-get install package”, and then run “apt-get dist-upgrade”.

If you try that, then the DPKG::Post-Invoke rule will clean out /var/cache/apt/archives when you install the individual package(s). When you then run the dist-upgrade, apt-get will have to download all the packages again.

Better just to get into the habit of running apt-get clean or autoclean occasionally when you want to reclaim some disk space.

a