[BLUG] power off CD?

So, my wife Priscilla makes a copy of a data CD. Some friends are in
the psychology dept at IU, and she volunteered for an experiment and
ended up with some kind of imaging info of her brain. I don't think
that's important to the story, but maybe. Anyway, she drags a couple
of extra files onto the disk in Windows (Vista), and it's ready to
give to her friend. She said to me "can you put this in you computer
and make sure that it works?" Sure.

So, we put the CD into the CD drive of my Ubuntu (Jaunty)
machine... it spins up, and ... my computer turns off. power off. As
if our power had gone out, but it hadn't.

I turned the computer back on, it started booting, got about half way
through the progress meter (before the login prompt) and... same
thing. Power off.

I turn the computer back on, remove the CD, and the computer boots
normally. With no applications running besides the core and the GUI,
I insert the CD again. It spins up, and the computer powers down
again.

I'm convinced, so I won't try it again. She takes the CD back
to her computer, and that computer reads it just fine.

We really don't need to solve this problem, but I'm curious if anyone
has any thoughts on what's going on here. I wouldn't know how to make
such a CD if I wanted that functionality.... Strange that it might
somehow happen inadvertantly...

David
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Command line magic on Twitter

On Tue, Dec 15, 2009 at 08:00:30PM GMT, Robert Freeman-Day [presgas@gmail.com] said the following:
>
> Commandlinefu also has some pretty nifty items in its repository.
>
> http://www.commandlinefu.com/commands/browse
>

Thanks, that's a neat one too. Didn't know about it.

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] Command line magic on Twitter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 15 Dec 2009, Mark Krenz wrote:

> Date: Tue, 15 Dec 2009 19:44:45 +0000
> From: Mark Krenz <mark@slugbug.org>
> Reply-To: Bloomington LINUX Users Group <blug@cs.indiana.edu>
> To: blug@cs.indiana.edu
> Subject: [BLUG] Command line magic on Twitter
>
>
> I know some of you probably don't use Twitter or scoff at it, but maybe
> its just because you haven't found anything interesting there yet. This
> may change your mind.
>
> I created a new account on Twitter called climagic, which you can
> follow here:
>
> http://twitter.com/climagic
>
> It stands for Command Line (Interface) Magic.
>
> Every day I will be posting a few command line demonstrations of
> different things you can do in bash as well as some helpful tips. I've
> categorized the demos out into easy, medium and advanced so that there
> is something for all users and will try to include various purposes.
> Hopefully you'll find new things you can do and better ways of doing old
> things.
>
> I also welcome suggestions of course.
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/

Commandlinefu also has some pretty nifty items in its repository.

http://www.commandlinefu.com/commands/browse

- ---Robert Freeman-Day
- ---------------
I would really like you to be on my side,
but the side you show me isn't what I had in mind.

- -Judybats
GPG Public Key:
http:keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xBA9DF9ED3E4C7D36

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksn6t4ACgkQup357T5MfTbO1ACfQEn62ffubldacXSh2VL7ANT2
AB4Ani2M5gp6ZCMrfHnc1rOkMBkYKFV9
=7q7S
-----END PGP SIGNATURE-----
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

[BLUG] Command line magic on Twitter

I know some of you probably don't use Twitter or scoff at it, but maybe
its just because you haven't found anything interesting there yet. This
may change your mind.

I created a new account on Twitter called climagic, which you can
follow here:

http://twitter.com/climagic

It stands for Command Line (Interface) Magic.

Every day I will be posting a few command line demonstrations of
different things you can do in bash as well as some helpful tips. I've
categorized the demos out into easy, medium and advanced so that there
is something for all users and will try to include various purposes.
Hopefully you'll find new things you can do and better ways of doing old
things.

I also welcome suggestions of course.

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

[BLUG] Strange sort behavior fixed with LANG

I was sorting an /etc/passwd and /etc/shadow file on the same machine
for the purpose of using the join command for an ldap import. I was
puzzled when I ran into little inconsistencies in my sorted output, like
this:

excerpt of sorted /etc/passwd:

joe:x:821:821::/home/joe:/bin/bash
joebob:x:1192:1192::/home/joebob:/bin/bash

excerpt of sorted /etc/shadow:

joebob:$1$uyt4hg46$Gf1EAPxzZ/Tm7X8BEgyBe0:12687:0:99999:7:::
joe:$1$uyt4hg46$Gf1EAPxzZ/Tm7X8BEgyBe0:12687:0:99999:7:::

What? Why would it put joe before joebob in one file and joebob before
joe in the other. All I had run to generate the output was this:

sort /etc/passwd > passwd-sorted
sort /etc/shadow > shadow-sorted

It turns out that when it comes to things like colons or
non-alphanumeric characters, sort will do strange things. So what you
have to do to get the right output is set the LANG=C variable in your
command line like this:

LANG=C sort filename

I can't believe I haven't run into this before. I hate to think how
many lists I may have constructed that had little errors in it now.

(And no that isn't a real password I used above for this e-mail.)

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] uptime no reset at 1024

I stand corrected.

It might be interesting to see how 'uptime(1)' gets the information.

A man of times(2) shows the return value (a clock_t) was the time when
the system was booted for 2.4 series kernels, but that's no longer the
case for 2.6 kernels.

Cheers,
Steven Black

On Mon, Nov 30, 2009 at 05:12:03PM +0000, Mark Krenz wrote:
>
> Your Occam's Razor smack down has been canceled out by evidence.
>
> Linux kernels USED TO wrap around their uptime at 497 days. This was
> due to how the uptime was stored in the kernel. As a measument of
> jiffies. Jiffies used to be set to 100 per second, but can now be
> adjusted to even 1000 per second. This is what that 100Hz, 250Hz, 1000Hz
> setting is in the kernel config. Thus the time stored in the uptime
> used to be limited to 2^32 seconds / 100jiffies / 86400 sec/day = 497days
>
> I noticed once that the shell server at Kiva, which is still running
> on the 2.2 kernel, wrapped around its uptime at 497 days like this.
>
>
> Anyways, I had heard offhand comments that the number of days might
> wrap around at 1024 days, so I was curious if something might happen at
> 1024 days. It wasn't really based on the above, it was just based on
> heresay and anecdotal evidence.
>
> After all, I found that the load average itself wraps around at
> 1024.0 on 2.4 kernels at least. And yes, I did see a machine reach a 1
> minute load average of over 15000. I had to determine this by using some
> logs I had that showed that it was wrapping around. The machine in
> question wasn't really using that much CPU, it was load that was based
> on deadlocking samba processes that were trying to run 'df' on a machine
> with hung NFS mounts.
>
> Mark
>
> On Mon, Nov 30, 2009 at 04:43:58PM GMT, Steven Black [blacks@indiana.edu] said the following:
> > Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
> > down.)
> >
> > The uptime is a time, so it is likely stored in a time_t. This means it
> > would normally be subject to the same year 2038 Unix Epoch wrap provided
> > the system used 32-bit time_t values.
> >
> > However, it is stored as a relative time, so the that the beginning of
> > this particular epoch was when the machine was started up. This means it
> > wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
> > you started it up. And again, this is only if it is a 32-bit machine
> > with a 32-bit time_t.
> >
> > Cheers,
> > Steven Black
> >
> > On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
> > >
> > > # w
> > > 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
> > >
> > > I was wondering if the days would wrap around at 1024 days. I guess
> > > they don't.
> > >
> > >
> > > --
> > > Mark Krenz
> > > Bloomington Linux Users Group
> > > http://www.bloomingtonlinux.org/
> >
> > _______________________________________________
> > BLUG mailing list
> > BLUG@linuxfan.com
> > http://mailman.cs.indiana.edu/mailman/listinfo/blug
> >
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug

--
Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] uptime no reset at 1024

Your Occam's Razor smack down has been canceled out by evidence.

Linux kernels USED TO wrap around their uptime at 497 days. This was
due to how the uptime was stored in the kernel. As a measument of
jiffies. Jiffies used to be set to 100 per second, but can now be
adjusted to even 1000 per second. This is what that 100Hz, 250Hz, 1000Hz
setting is in the kernel config. Thus the time stored in the uptime
used to be limited to 2^32 seconds / 100jiffies / 86400 sec/day = 497days

I noticed once that the shell server at Kiva, which is still running
on the 2.2 kernel, wrapped around its uptime at 497 days like this.

Anyways, I had heard offhand comments that the number of days might
wrap around at 1024 days, so I was curious if something might happen at
1024 days. It wasn't really based on the above, it was just based on
heresay and anecdotal evidence.

After all, I found that the load average itself wraps around at
1024.0 on 2.4 kernels at least. And yes, I did see a machine reach a 1
minute load average of over 15000. I had to determine this by using some
logs I had that showed that it was wrapping around. The machine in
question wasn't really using that much CPU, it was load that was based
on deadlocking samba processes that were trying to run 'df' on a machine
with hung NFS mounts.

Mark

On Mon, Nov 30, 2009 at 04:43:58PM GMT, Steven Black [blacks@indiana.edu] said the following:
> Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
> down.)
>
> The uptime is a time, so it is likely stored in a time_t. This means it
> would normally be subject to the same year 2038 Unix Epoch wrap provided
> the system used 32-bit time_t values.
>
> However, it is stored as a relative time, so the that the beginning of
> this particular epoch was when the machine was started up. This means it
> wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
> you started it up. And again, this is only if it is a 32-bit machine
> with a 32-bit time_t.
>
> Cheers,
> Steven Black
>
> On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
> >
> > # w
> > 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
> >
> > I was wondering if the days would wrap around at 1024 days. I guess
> > they don't.
> >
> >
> > --
> > Mark Krenz
> > Bloomington Linux Users Group
> > http://www.bloomingtonlinux.org/
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug