Mon, 06 Apr 2009
getrusage() and another example of Linux failure.
So I'm writing some code for work and I need to know the current stack usage. One would think getrusage() would be nice to use. Think again. To quote the manual page on Ubuntu:
struct rusage {
struct timeval ru_utime; /* user time used */
struct timeval ru_stime; /* system time used */
long ru_maxrss; /* maximum resident set size */
long ru_ixrss; /* integral shared memory size */
long ru_idrss; /* integral unshared data size */
long ru_isrss; /* integral unshared stack size */
long ru_minflt; /* page reclaims */
long ru_majflt; /* page faults */
long ru_nswap; /* swaps */
long ru_inblock; /* block input operations */
long ru_oublock; /* block output operations */
long ru_msgsnd; /* messages sent */
long ru_msgrcv; /* messages received */
long ru_nsignals; /* signals received */
long ru_nvcsw; /* voluntary context switches */
long ru_nivcsw; /* involuntary context switches */
};
[...]
The above struct was taken from 4.3BSD Reno. Not all fields are mean-
ingful under Linux. In linux 2.4 only the fields ru_utime, ru_stime,
ru_minflt, and ru_majflt are maintained. Since Linux 2.6, ru_nvcsw and
ru_nivcsw are also maintained.
I can understand having the same struct for portability reasons. It's nice that code can be portable between the two at compile time but this is opening itself up to run-time problems if code assumes all the members of the struct will be populated.
I'm not sure why it's only barely implemented but it's quite annoying. The same function call on FreeBSD gives all the information, and the manual page under FreeBSD has useful information on what each of the members of the struct means. Linux fails, again.
gdb output on Linux:
(gdb) p/x *usage
$1 = {ru_utime = {tv_sec = 0x0, tv_usec = 0xfa0}, ru_stime = {tv_sec = 0x0,
tv_usec = 0xbb83}, ru_maxrss = 0x0, ru_ixrss = 0x0, ru_idrss = 0x0,
ru_isrss = 0x0, ru_minflt = 0x2fe, ru_majflt = 0x0, ru_nswap = 0x0,
ru_inblock = 0x0, ru_oublock = 0x0, ru_msgsnd = 0x0, ru_msgrcv = 0x0,
ru_nsignals = 0x0, ru_nvcsw = 0x7b, ru_nivcsw = 0x1}
(gdb)
gdb output on FreeBSD:
(gdb) p/x *usage
$3 = {ru_utime = {tv_sec = 0x0, tv_usec = 0x0}, ru_stime = {tv_sec = 0x0,
tv_usec = 0x3ac7}, ru_maxrss = 0x8e8, ru_ixrss = 0x3f8, ru_idrss = 0xec,
ru_isrss = 0x100, ru_minflt = 0xeb, ru_majflt = 0x0, ru_nswap = 0x0,
ru_inblock = 0x0, ru_oublock = 0x0, ru_msgsnd = 0x0, ru_msgrcv = 0x0,
ru_nsignals = 0x0, ru_nvcsw = 0xc, ru_nivcsw = 0x1}
(gdb)
posted at: 16:46 | tags: linux, freebsd, code | path: /entries/geek | permanent link to this entry
Wed, 22 Nov 2006
Why Don't They Just uuencode the File in the Filename?
Can someone please explain these updated packages and how the version numbering works. Multiple ubuntu kiddies have tried on multiple occasions and it just never makes any sense to me.
Ubuntu 5.10: firefox 1.5.dfsg+1.5.0.8-0ubuntu0.5.10 firefox-dev 1.5.dfsg+1.5.0.8-0ubuntu0.5.10 Ubuntu 6.06 LTS: firefox 1.5.dfsg+1.5.0.8-0ubuntu0.6.06 firefox-dev 1.5.dfsg+1.5.0.8-0ubuntu0.6.06 libnspr-dev 1.5.dfsg+1.5.0.8-0ubuntu0.6.06 libnspr4 1.5.dfsg+1.5.0.8-0ubuntu0.6.06 libnss-dev 1.5.dfsg+1.5.0.8-0ubuntu0.6.06 libnss3 1.5.dfsg+1.5.0.8-0ubuntu0.6.06
Those were taken from here. But honestly, what the hell do they mean? I'd like to know what version of a piece of software I'm running, and it shouldn't take a complicated explanation of some almost random string of characters to make me understand it.
Though nothing beats the way they name their CUPS packages...
The problem can be corrected by upgrading the affected package to version 1.1.20final+cvs20040330-4ubuntu16.5. In general, a standard system upgrade is sufficient to effect the necessary changes.
posted at: 07:34 | tags: ubuntu, linux, stupidity | path: /entries/rant | permanent link to this entry
Thu, 27 Apr 2006
Using Linux means you support terroism?
If you ever want to get a good laugh out of one political nut-job I'd highly suggest this article.
I wonder if anyone has told Tristan that IBM laptops are now made in China, and that using them means you are "opening yourself up to Chinese hackers."
It's things like this that make me glad I learned a long time ago that anything to extreme is a bad thing. Wow, just wow.
posted at: 11:35 | tags: humor, linux | path: /entries/humor | permanent link to this entry
Wed, 15 Mar 2006
Honestly, why even use it?
So at work I had to do some work on one of our syslog servers today. In the process of debugging an interesting misconception I had of Solaris 9's syslog implementation I came across a machine sending syslog messages with timestamps that were roughly an hour in the future. We have an ntpd running on this network (it's an isolated network) so I sent a message off to a co-worker asking him to look into it as I was busy at the time. I go about my business and about 30 minutes later I've fixed the syslog problem but am still noticing bizarre timestamps coming from this one Gentoo box. I login and start poking around, and this is where my hatred for Linux (in this case Gentoo, though I tend to blame it entirely on GNU/Linux as a whole) shows.
A quick ps listing shows ntpd running, not ntp-client. No big deal, I stop the ntpd service, remove it from starting on boot, and go to fire up ntp-client. A quick check of /etc/ntp.conf shows the appropriate (internal) time server listed so I figure all is well to start up the ntp-client service. Well, /etc/init.d/ntp-client returns some message about not being able to contact pool.ntp.org. That's odd, our internal timeserver was listed in /etc/ntp.conf. I take a look at /etc/init.d/ntp-client to see if it specifies a configuration file other than the (logical) /etc/ntp.conf, and to my surprise it does. Replacing pool.ntp.org with the proper ntp server in /etc/conf.d/ntp-client and starting up the ntp-client service worked no problem. I suppose all this could have been avoided if I took the time to read all the manpages involved, but that would have taken more time then I took to debug the problem in the first place, and even then I'm not guaranteed that the documentation is even remotely accurate (more on this below).
I'm sure there is some crazy (this is the part where I wave my hands in the air) explanation as to why the files are layed out like that, but quite frankly unless the explanation involves a cure for cancer or Elizabeth Hurley naked in my bedroom I will have a hard time getting behind it (the explanation, not Elizabeth Hurley). I mean honestly, someone needs to beat these Linux kiddies over the head with a copy of hier(7). I see no logical reason for having a file system layout where things can be thrown about all willy-nilly and expect anyone who has to administer it to stay sane.
I guess the other thing that bothers me is the complete lack of any solid engineering in it. A kernel is not that useful without a userland. A userland is entirely useless without a kernel. With those two truths in mind I don't understand how anyone can advocate using Linux for important things. Kernel and userland are tied so closely together that they should be developed as one. That way the userland is never lagging behind the kernel. The cherry on top is a system who'se documentation is also developed in synch with the rest of the system. An example of this is when I eventually remembered the name of the command to schedule services to start/stop at the various runlevels in Gentoo (rc-update). As I wanted to get a feel for the arguments I read the manpage. I noticed two things at first, one was the argument -s (I think that was it) to show the status, and the second was to see also: rc-status(8). As rc-status(8) sounded exactly like something I was interested in I type 'man rc-status' and get no result. Yay for crappy documentation!
Of course documentation can be behind the times in FreeBSD, but that is far less the often the case than in GNU/Linux-land. The solid engineering behind FreeBSD far out-does the shoddy, cobbled together, nature of any Linux offering..
posted at: 17:44 | tags: gentoo, linux, stupidity | path: /entries/rant | permanent link to this entry
