Is this data really stored in the RAM? - Ubuntu

This is a discussion on Is this data really stored in the RAM? - Ubuntu ; I came across an article on PC security and encryption http://citp.princeton.edu/memory/exp/ http://citp.princeton.edu/memory/ and found an interesting command. sudo strings /dev/mem | less printed what amounted to a history of this PCs activity. Is this reading a file stored somewhere on ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 38

Thread: Is this data really stored in the RAM?

  1. Is this data really stored in the RAM?

    I came across an article on PC security and encryption
    http://citp.princeton.edu/memory/exp/
    http://citp.princeton.edu/memory/
    and found an interesting command.

    sudo strings /dev/mem | less

    printed what amounted to a history of this PCs activity.

    Is this reading a file stored somewhere on the PC or is it reading
    straight out of the RAM?

    I'm thinking, might be a useful place to look for clues to random hard
    lockups and stuff.
    (also, see what the kids are downloading while pretending to do their
    homework... *g*)
    grepped for password and found nothing so it doesn't appear to be a
    security risk...

  2. Re: Is this data really stored in the RAM?

    On Fri, 22 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >I came across an article on PC security and encryption
    >http://citp.princeton.edu/memory/exp/
    >http://citp.princeton.edu/memory/
    >and found an interesting command.
    >
    >sudo strings /dev/mem | less
    >
    >printed what amounted to a history of this PCs activity.


    Well.... yeah, that's somewhat correct, and that's why the device is
    normally given permissions/ownership of crw-r----- root:kmem or
    similar.

    >Is this reading a file stored somewhere on the PC or is it reading
    >straight out of the RAM?


    In Linux, _everything_ is file, but what you want to be looking for
    is in the disk file 'devices.txt' which may be in your kernel source
    tree:

    1 char Memory devices
    1 = /dev/mem Physical memory access
    2 = /dev/kmem Kernel virtual memory access
    3 = /dev/null Null device
    4 = /dev/port I/O port access
    5 = /dev/zero Null byte source
    6 = /dev/core OBSOLETE - replaced by /proc/kcore
    7 = /dev/full Returns ENOSPC on write
    8 = /dev/random Nondeterministic random number gen.
    9 = /dev/urandom Faster, less secure random number gen.
    10 = /dev/aio Asyncronous I/O notification interface
    11 = /dev/kmsg Writes to this come out as printk's

    There are all kinds of interesting things hidden away if you know where
    to look, but yes, that is the RAM you are looking at.

    >I'm thinking, might be a useful place to look for clues to random hard
    >lockups and stuff.


    Usually not. If you look at your process tree (ps auwx), you will find
    the typical system has a shedload of processes running. Which one wrote
    this or that message? For lockups, it's often a case that the system
    doesn't have time to write anything useful about a process that went
    out to lunch.

    >(also, see what the kids are downloading while pretending to do their
    >homework... *g*)


    If you don't trust your kids, don't give them access to the computer.
    This kind of sneakery is no substitute for proper parenting.

    >grepped for password and found nothing so it doesn't appear to be a
    >security risk...


    That may or may not be luck, but recall by looking at the contents of
    /etc/shadow (or even /etc/passwd if you aren't using the shadow suite)
    that the stored data is the _hash_ of the password, not the actual
    password itself. Applications that do authentication know to hash
    the supplied password, and THEN compare the hash with the authentication
    file. However it's a well known fact that people will key in their
    password when the program is asking for a login name, and similar, and
    the plain text passwords are often found in security logs (which is why
    they are not normally readable by lusers.

    Old guy

  3. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:qYIvj.12895$0w.4473@newssvr27.news.prodigy.ne t...
    > I came across an article on PC security and encryption
    > http://citp.princeton.edu/memory/exp/
    > http://citp.princeton.edu/memory/
    > and found an interesting command.
    >
    > sudo strings /dev/mem | less
    >
    > printed what amounted to a history of this PCs activity.
    >
    > Is this reading a file stored somewhere on the PC or is it reading
    > straight out of the RAM?


    It is from RAM and doesn't include the paged memory AFAIK.
    You will only find stuff if you have a program running that has read them
    into RAM.
    It is mainly transient too so even if a password was in RAM a minute or two
    ago it may have gone when you looked.
    I am surprised that if you greped for password it didn't find it as the grep
    string should be in RAM so the comparison could be made.

    >
    > I'm thinking, might be a useful place to look for clues to random hard
    > lockups and stuff.
    > (also, see what the kids are downloading while pretending to do their
    > homework... *g*)
    > grepped for password and found nothing so it doesn't appear to be a
    > security risk...



  4. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >
    >
    > "clay" wrote in message
    > news:qYIvj.12895$0w.4473@newssvr27.news.prodigy.ne t...
    >> I came across an article on PC security and encryption
    >> http://citp.princeton.edu/memory/exp/
    >> http://citp.princeton.edu/memory/
    >> and found an interesting command.
    >>
    >> sudo strings /dev/mem | less
    >>
    >> printed what amounted to a history of this PCs activity.
    >>
    >> Is this reading a file stored somewhere on the PC or is it reading
    >> straight out of the RAM?

    >
    > It is from RAM and doesn't include the paged memory AFAIK.
    > You will only find stuff if you have a program running that has read
    > them into RAM.
    > It is mainly transient too so even if a password was in RAM a minute or
    > two ago it may have gone when you looked.
    > I am surprised that if you greped for password it didn't find it as the
    > grep string should be in RAM so the comparison could be made.
    >
    >>


    That's why I'm curious... If it is indeed volatile data and not data
    written to a logfile somewhere, I'm seeing stuff that I did on this PC
    weeks or months ago.
    The box is up 24-7 because it's a MythTV slave but it's been shut off
    and/or restarted many times.
    Good point about the grep. If it is reading the memory realtime, grep
    should find itself...

  5. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    >...to look, but yes, that is the RAM you are looking at.
    >
    >> I'm thinking, might be a useful place to look for clues to random hard
    >> lockups and stuff.

    >
    > Usually not. If you look at your process tree (ps auwx), you will find
    > the typical system has a shedload of processes running. Which one wrote
    > this or that message? For lockups, it's often a case that the system
    > doesn't have time to write anything useful about a process that went
    > out to lunch.
    >

    My thought was the very last thing recorded in memory would be what went
    wrong to cause the lockup. Maybe even a flood of data as a program or
    service goes haywire...


    >> (also, see what the kids are downloading while pretending to do their
    >> homework... *g*)

    >
    > If you don't trust your kids, don't give them access to the computer.
    > This kind of sneakery is no substitute for proper parenting.


    Regrettably, no kids but I agree with your philosophy.
    >
    >> grepped for password and found nothing so it doesn't appear to be a
    >> security risk...

    >
    > That may or may not be luck, but recall by looking at the contents of
    > /etc/shadow (or even /etc/passwd if you aren't using the shadow suite)
    > that the stored data is the _hash_ of the password, not the actual
    > password itself. Applications that do authentication know to hash
    > the supplied password, and THEN compare the hash with the authentication
    > file. However it's a well known fact that people will key in their
    > password when the program is asking for a login name, and similar, and
    > the plain text passwords are often found in security logs (which is why
    > they are not normally readable by lusers.
    >

    Apparently I have shadow (news to me!) Saw the hashes and no oopses
    keying pw as login.
    ....so much to learn.

  6. Re: Is this data really stored in the RAM?

    clay schreef:
    > dennis@home wrote:
    >>
    >>
    >> "clay" wrote in message
    >> news:qYIvj.12895$0w.4473@newssvr27.news.prodigy.ne t...
    >>> I came across an article on PC security and encryption
    >>> http://citp.princeton.edu/memory/exp/
    >>> http://citp.princeton.edu/memory/
    >>> and found an interesting command.
    >>>
    >>> sudo strings /dev/mem | less
    >>>
    >>> printed what amounted to a history of this PCs activity.
    >>>
    >>> Is this reading a file stored somewhere on the PC or is it reading
    >>> straight out of the RAM?

    >>
    >> It is from RAM and doesn't include the paged memory AFAIK.
    >> You will only find stuff if you have a program running that has read
    >> them into RAM.
    >> It is mainly transient too so even if a password was in RAM a minute
    >> or two ago it may have gone when you looked.
    >> I am surprised that if you greped for password it didn't find it as
    >> the grep string should be in RAM so the comparison could be made.
    >>
    >>>

    >
    > That's why I'm curious... If it is indeed volatile data and not data
    > written to a logfile somewhere, I'm seeing stuff that I did on this PC
    > weeks or months ago.
    > The box is up 24-7 because it's a MythTV slave but it's been shut off
    > and/or restarted many times.
    > Good point about the grep. If it is reading the memory realtime, grep
    > should find itself...


    A few days ago there was this discussion on Slashdot that touches the
    subject of memory retention:
    http://it.slashdot.org/article.pl?sid=08/02/21/1543234

  7. Re: Is this data really stored in the RAM?



    "Dirk T. Verbeek" wrote in message
    news:47c08041$0$14358$e4fe514c@news.xs4all.nl...
    > clay schreef:
    >> dennis@home wrote:
    >>>
    >>>
    >>> "clay" wrote in message
    >>> news:qYIvj.12895$0w.4473@newssvr27.news.prodigy.ne t...
    >>>> I came across an article on PC security and encryption
    >>>> http://citp.princeton.edu/memory/exp/
    >>>> http://citp.princeton.edu/memory/
    >>>> and found an interesting command.
    >>>>
    >>>> sudo strings /dev/mem | less
    >>>>
    >>>> printed what amounted to a history of this PCs activity.
    >>>>
    >>>> Is this reading a file stored somewhere on the PC or is it reading
    >>>> straight out of the RAM?
    >>>
    >>> It is from RAM and doesn't include the paged memory AFAIK.
    >>> You will only find stuff if you have a program running that has read
    >>> them into RAM.
    >>> It is mainly transient too so even if a password was in RAM a minute or
    >>> two ago it may have gone when you looked.
    >>> I am surprised that if you greped for password it didn't find it as the
    >>> grep string should be in RAM so the comparison could be made.
    >>>
    >>>>

    >>
    >> That's why I'm curious... If it is indeed volatile data and not data
    >> written to a logfile somewhere, I'm seeing stuff that I did on this PC
    >> weeks or months ago.
    >> The box is up 24-7 because it's a MythTV slave but it's been shut off
    >> and/or restarted many times.
    >> Good point about the grep. If it is reading the memory realtime, grep
    >> should find itself...

    >
    > A few days ago there was this discussion on Slashdot that touches the
    > subject of memory retention:
    > http://it.slashdot.org/article.pl?sid=08/02/21/1543234


    I have used that effect to design extended refresh battery backed up DRAM
    systems before now so its not something new.
    However it doesn't explain what the OP is seeing.
    The fact that he sees old data but not the grep process suggest he is not
    reading system RAM at all.
    How likely is it that the links on the disk are corrupt and /dev/mem is
    actually pointing at something like the swap file?
    AFAICS its either that or a bug, anyone else tried it?


  8. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >...
    >>>
    >>> That's why I'm curious... If it is indeed volatile data and not data
    >>> written to a logfile somewhere, I'm seeing stuff that I did on this
    >>> PC weeks or months ago.
    >>> The box is up 24-7 because it's a MythTV slave but it's been shut off
    >>> and/or restarted many times.
    >>> Good point about the grep. If it is reading the memory realtime, grep
    >>> should find itself...

    >>
    >> A few days ago there was this discussion on Slashdot that touches the
    >> subject of memory retention:
    >> http://it.slashdot.org/article.pl?sid=08/02/21/1543234

    >
    > I have used that effect to design extended refresh battery backed up
    > DRAM systems before now so its not something new.
    > However it doesn't explain what the OP is seeing.
    > The fact that he sees old data but not the grep process suggest he is
    > not reading system RAM at all.
    > How likely is it that the links on the disk are corrupt and /dev/mem is
    > actually pointing at something like the swap file?
    > AFAICS its either that or a bug, anyone else tried it?


    I checked it again. Did a grep for PW and other things, then grepped for
    grep. grep didn't return any grepping going on.
    There's a bit about RAID in there. I removed the (software) RAID0 and
    drives a month ago.
    Also, references to movies and stuff I haven't looked at in days. A
    newsgroup post I read yesterday.
    Interesting, the random bits it chooses to store in there...

    ct@wimp:~$ sudo strings /dev/mem | grep raid
    PCI RAID
    PCI RAID
    RAID SATA
    RAID1 set is in Sync state - an improper shutdown has been detected
    RAID1 set is in Rebuild status
    RAID1 set is in Critical status
    E9EPress "Enter" to create RAID
    RAID set
    EStriped = RAID 0
    Mirrored = RAID 1
    (RAID 0) set
    create a striped (RAID 0)
    striped (RAID 0) set
    striped (RAID 0) set
    striped (RAID 0) set
    ct@wimp:~$

  9. Re: Is this data really stored in the RAM?

    On 2008-02-24, clay wrote:
    > dennis@home wrote:
    >>...
    >>>>
    >>>> That's why I'm curious... If it is indeed volatile data and not data
    >>>> written to a logfile somewhere, I'm seeing stuff that I did on this
    >>>> PC weeks or months ago.
    >>>> The box is up 24-7 because it's a MythTV slave but it's been shut off
    >>>> and/or restarted many times.
    >>>> Good point about the grep. If it is reading the memory realtime, grep
    >>>> should find itself...
    >>>
    >>> A few days ago there was this discussion on Slashdot that touches the
    >>> subject of memory retention:
    >>> http://it.slashdot.org/article.pl?sid=08/02/21/1543234

    >>
    >> I have used that effect to design extended refresh battery backed up
    >> DRAM systems before now so its not something new.
    >> However it doesn't explain what the OP is seeing.
    >> The fact that he sees old data but not the grep process suggest he is
    >> not reading system RAM at all.
    >> How likely is it that the links on the disk are corrupt and /dev/mem is
    >> actually pointing at something like the swap file?
    >> AFAICS its either that or a bug, anyone else tried it?

    >
    > I checked it again. Did a grep for PW and other things, then grepped for
    > grep. grep didn't return any grepping going on.
    > There's a bit about RAID in there. I removed the (software) RAID0 and
    > drives a month ago.
    > Also, references to movies and stuff I haven't looked at in days. A
    > newsgroup post I read yesterday.
    > Interesting, the random bits it chooses to store in there...
    >
    > ct@wimp:~$ sudo strings /dev/mem | grep raid
    > PCI RAID
    > PCI RAID
    > RAID SATA
    > RAID1 set is in Sync state - an improper shutdown has been detected
    > RAID1 set is in Rebuild status
    > RAID1 set is in Critical status
    > E9EPress "Enter" to create RAID
    > RAID set
    > EStriped = RAID 0
    > Mirrored = RAID 1
    > (RAID 0) set
    > create a striped (RAID 0)
    > striped (RAID 0) set
    > striped (RAID 0) set
    > striped (RAID 0) set
    > ct@wimp:~$


    just a theory...
    the old stuff that can be seen might be a result of a program being
    loaded and doing some checks, like is this movie in my favourites? or
    what or was my last state - check if we're going there again.

    output from ... |grep grep doesn't show up because mem was dumped
    first and then passed thru grep.
    A subsequent ... |grep grep doesn't show up because grep sends the
    output to stdout and quits

    perhaps the raid warnings that are still being sent are trapped in
    some "system state log" ??? because the raid installation was faulty
    at time of removal, or a config somewhere is still looking for raid1
    dunno about raid

    like I said, just a theory

    --
    l'air du temps


  10. Re: Is this data really stored in the RAM?

    jane doa wrote:
    >...
    >
    > just a theory...
    > the old stuff that can be seen might be a result of a program being
    > loaded and doing some checks, like is this movie in my favourites? or
    > what or was my last state - check if we're going there again.
    >
    > output from ... |grep grep doesn't show up because mem was dumped
    > first and then passed thru grep.
    > A subsequent ... |grep grep doesn't show up because grep sends the
    > output to stdout and quits
    >
    > perhaps the raid warnings that are still being sent are trapped in
    > some "system state log" ??? because the raid installation was faulty
    > at time of removal, or a config somewhere is still looking for raid1
    > dunno about raid
    >
    > like I said, just a theory
    >


    Could be from Places>Recent Documents. Hadn't thought of that.
    That doesn't change much since the box is mostly just a MythTV
    slave/email box.

    Very likely a good theory re the RAID. I'm quite sure I didn't remove it
    correctly or completely.

    Thanks for the insight on grep.
    ....so much to learn.

  11. Re: Is this data really stored in the RAM?

    On Sat, 23 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >Moe Trin wrote:


    >> For lockups, it's often a case that the system doesn't have time to
    >> write anything useful about a process that went out to lunch.

    >
    >My thought was the very last thing recorded in memory would be what went
    >wrong to cause the lockup. Maybe even a flood of data as a program or
    >service goes haywire...


    I don't see the systems locking up that badly - usually it's a single
    process that bombs, and the rest of the world continues merrily on it's
    way - and what MIGHT be your better choice is to enable core files and
    hope that the bad guy drops a core to be looked at. This is rare
    enough that many people are running with a ulimit that blocks core
    files

    [compton ~]$ ulimit -c
    0
    [compton ~]$

    and you'd have to set that to some reasonable number (perhaps 2-3 Megs)
    if you were interested. 'help ulimit' provides clues as this is a
    shell built-in command. This is usually set in /etc/profile, but if you
    are using a GUI login, it is set in the display manager startup files
    (man gdm kdm wdm xdm - depending on which you are using).

    >>> (also, see what the kids are downloading while pretending to do their
    >>> homework... *g*)

    >>
    >> If you don't trust your kids, don't give them access to the computer.
    >> This kind of sneakery is no substitute for proper parenting.

    >
    >Regrettably, no kids but I agree with your philosophy.


    It's convenient to forget the tricks you pulled on your parents, and
    all to many people today think that technology is the answer. If the
    kid has a clue (and a surprising number of them do), there are ways to
    circumvent this type of "parental control" - the easiest being to go to
    a different computer.

    >Apparently I have shadow (news to me!)


    Most Linux distributions transitioned to the shadow system in the mid-late
    1990s. Some fields in the password file need to be readable by everyone
    (such as names, and G/UIDs - fields 1, 3-5), which is why the file is
    world readable. Things that need access to the password hash are nearly
    always running as root, which is why the shadow and gshadow files were
    set to 0600.

    >Saw the hashes and no oopses keying pw as login.


    The 'oopses' happen more often than people like to admit. Another
    place to look for them is in your 'history' - again, people miscueing
    about when to type the password.

    >...so much to learn.


    Yup. There are over 450 HOWTOs and mini-howtos totalling a staggering
    3.86 million words - the equivalent of 11638 pages of text. And then
    because you don't have enough reading to do, the Linux Documentation
    Project (http://tldp.org/guides.html) has 35 entire books you can
    download if they aren't on your system already.

    Old guy

  12. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    > On Sat, 23 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    > , clay wrote:
    >
    >> Moe Trin wrote:

    >
    >>> For lockups, it's often a case that the system doesn't have time to
    >>> write anything useful about a process that went out to lunch.

    >> My thought was the very last thing recorded in memory would be what went
    >> wrong to cause the lockup. Maybe even a flood of data as a program or
    >> service goes haywire...

    >
    > I don't see the systems locking up that badly - usually it's a single
    > process that bombs, and the rest of the world continues merrily on it's
    > way - and what MIGHT be your better choice is to enable core files and
    > hope that the bad guy drops a core to be looked at. This is rare
    > enough that many people are running with a ulimit that blocks core
    > files
    >
    > [compton ~]$ ulimit -c
    > 0
    > [compton ~]$
    >
    > and you'd have to set that to some reasonable number (perhaps 2-3 Megs)
    > if you were interested. 'help ulimit' provides clues as this is a
    > shell built-in command. This is usually set in /etc/profile, but if you
    > are using a GUI login, it is set in the display manager startup files
    > (man gdm kdm wdm xdm - depending on which you are using).
    >


    ok, I'm back.
    Started reading your post, all set to reply, and total lockup...
    I was just going to say, doesn't happen all that often. How convenient
    it happens now.
    Unplugged everything from the box and plugged it back in. Tried to ssh
    into it, tried to ping it, nothing...
    No HDD activity, no network activity. Should have been streaming a
    recording to the MythTV frontend but that playback froze. pan was
    downloading some stuff and there's a 23 minute gap in that so it stopped.
    Appears the mythbackend continued recording during my attempts to get it
    back so that system did continue to run. Only ends when I pulled the plug.
    ....time to enable core files, ya think?

    >...
    >
    >> ...so much to learn.

    >
    > Yup. There are over 450 HOWTOs and mini-howtos totalling a staggering
    > 3.86 million words - the equivalent of 11638 pages of text. And then
    > because you don't have enough reading to do, the Linux Documentation
    > Project (http://tldp.org/guides.html) has 35 entire books you can
    > download if they aren't on your system already.
    >


    Thanks for the link. I'll get those read right away.

    btw, thanks for hanging around here and sharing your knowledge. Taught
    me a bunch of stuff... mostly that I have a lot to learn yet.

    && try and stay out of icu, will ya?


  13. Re: Is this data really stored in the RAM?

    On Sun, 24 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >Moe Trin wrote:


    >> I don't see the systems locking up that badly - usually it's a
    >> single process that bombs, and the rest of the world continues
    >> merrily on it's way - and what MIGHT be your better choice is to
    >> enable core files and hope that the bad guy drops a core to be
    >> looked at. This is rare enough that many people are running with
    >> a ulimit that blocks core files


    >ok, I'm back.
    >Started reading your post, all set to reply, and total lockup...
    >I was just going to say, doesn't happen all that often. How convenient
    >it happens now.


    That's not nice. Is there any pattern of what you are doing when it
    locks up?

    >Unplugged everything from the box and plugged it back in. Tried to ssh
    >into it, tried to ping it, nothing...


    Does it normally respond to pings? Normally, the first thing on a
    headed system that I'd check (all of my servers are headless, with no
    display or keyboard) is to poke the NumLock or ScrollLock key, and see
    if the keyboard LEDs follow. If not, that says the interrupts are
    blocked. If it does respond to that, I'll usually try to come in over
    the network - didn't work for you. Third step is then to poke the left
    control key, left Alt key, and the BackArrow (backspace) keys all at
    once. If the keyboard is accepting things, that should kill X, and all
    of the applications running under X. If you are running a GUI login,
    it will restart X as well, but if you are running a text login, it will
    bring you to a command prompt as a user. A slightly better trick is to
    try to switch to another virtual console. This is done by pressing the
    left control, left Alt, and F2 keys at the same time. That will bring
    you to another login prompt, but at the text level. Don't try to start
    another X session, but use tools like 'ps' to see what's going on. To
    return to X, you would press the left Alt key and one F key beyond the
    number of gettys (virtual terminals) you are running (for example:

    [compton ~]$ ps aux | grep getty
    root 291 0.0 0.0 724 0 3 SW Aug 26 0:00 (mingetty)
    root 292 0.0 0.0 724 0 4 SW Aug 26 0:00 (mingetty)
    root 12849 0.0 0.0 724 28 2 S Feb 3 0:00 (mingetty)
    [compton ~]$

    here, I'm running four virtual terminals, so Alt+F5 would bring me
    back to the original X session.) The mingetty for VC1 is exec'ed to my
    login shell, which is why it doesn't show here. Finally, depending on
    how you kernel was compiled, the combination of left Alt key and the
    SysRq key may attract the kernels attention if it's waiting for other
    stuff.

    >No HDD activity, no network activity. Should have been streaming a
    >recording to the MythTV frontend but that playback froze. pan was
    >downloading some stuff and there's a 23 minute gap in that so it stopped.


    That smells like a blocked interrupt. How did 'time of day' show? The
    system keeps track of time by using IRQ0, and those interrupts occur at
    a high rate and also the highest priority. Also, if there are cron
    tasks scheduled, did they run? This should show up in /var/log/cron or
    similar. All of my systems show disk activity once a minute. Because
    I'm also using network file systems on all but two of the systems,
    there is also a momentary flash of network activity once a minute, but
    both of those are easy to miss if you happen to blink at the same time
    the LED flashes.

    >Appears the mythbackend continued recording during my attempts to get it
    >back so that system did continue to run. Only ends when I pulled the plug.
    >...time to enable core files, ya think?


    Yes, and I'd also think about watching /proc/interrupts, but that can be
    tedious. Are you running the system 24/7?

    >Thanks for the link. I'll get those read right away.


    Reading them all is going to take a lot of time. I've been using Linux
    since ~1993, and still haven't read all of the HOWTOs. The books can
    also be more than you need. What _is_ helpful is to know that the
    documentation exists, and have some idea what it covers.

    >btw, thanks for hanging around here and sharing your knowledge. Taught
    >me a bunch of stuff... mostly that I have a lot to learn yet.


    Honestly, this stuff isn't learned over night, or even over a semester.
    All you can do is try. ;-)

    >&& try and stay out of icu, will ya?


    Not my call. The staff are real jewels, but like most, I'd REALLY
    rather be doing other things outside, than being flat on my back with
    all those wires and pipes coming out from under the covers. I'm
    probably home-bound for another couple of weeks. Thanks for the
    concern though.

    Old guy

  14. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    ....>> ok, I'm back.
    >> Started reading your post, all set to reply, and total lockup...
    >> I was just going to say, doesn't happen all that often. How convenient
    >> it happens now.

    >
    > That's not nice. Is there any pattern of what you are doing when it
    > locks up?


    No real pattern. Sometimes scheduling MythTV recordings, sometimes
    editing recordings stored on this box or stored on the master. Emailing,
    browsing the web...
    It doesn't happen often, less than once a month.
    When it does, the display is frozen, cursor stops blinking if it was,
    and basically becomes a screenshot.

    >
    >> Unplugged everything from the box and plugged it back in. Tried to ssh
    >> into it, tried to ping it, nothing...

    >
    > Does it normally respond to pings?


    When it's not locked up, it does.

    Normally, the first thing on a
    > headed system that I'd check (all of my servers are headless, with no
    > display or keyboard) is to poke the NumLock or ScrollLock key, and see
    > if the keyboard LEDs follow....


    LEDs don't respond. Numlock LED is on and it stays on when I press the
    key. Ctrl+Alt+Backspace, F1, etc does nothing...
    I've tried unplugging and plugging into a different USB port, plugging
    in a different keyboard, plugging in a PS2 keyboard.
    No joy...

    btw, running Ubuntu 6.10 Gnome. It's a pretty esoteric box that I put
    together 10 years ago. i850 chipset, 1GB of PC1066 Rambus RIMM. Hardware
    might just be a little too flaky for Ubuntu.

    >...
    >> No HDD activity, no network activity. Should have been streaming a
    >> recording to the MythTV frontend but that playback froze. pan was
    >> downloading some stuff and there's a 23 minute gap in that so it stopped.

    >
    > That smells like a blocked interrupt. How did 'time of day' show?

    The clock is (usually) not visible on the menubar when it locks. Be
    interesting to see if it's still running.

    > ...
    >> Appears the mythbackend continued recording during my attempts to get it
    >> back so that system did continue to run. Only ends when I pulled the plug.
    >> ...time to enable core files, ya think?

    >
    > Yes, and I'd also think about watching /proc/interrupts, but that can be
    > tedious. Are you running the system 24/7?
    >


    It runs 24/7 as a slave on my MythTV system. No cron task today but it
    gets a workout commflagging and transcoding recordings, memory intensive
    stuff. I pile on an unrar job pretty much brings it to it's knees. Chugs
    away though... usually.

    ct@wimp:~$ cat /proc/interrupts
    CPU0 CPU1
    0: 6135094 0 IO-APIC-edge timer
    5: 0 0 IO-APIC-edge MPU401 UART
    7: 0 0 IO-APIC-edge parport0
    8: 3 0 IO-APIC-edge rtc
    14: 638957 0 IO-APIC-edge ide0
    15: 4042908 0 IO-APIC-edge ide1
    169: 1 0 IO-APIC-level acpi
    177: 1124384 0 IO-APIC-level libata, ide2, uhci_hcd:usb3,
    ohci1394, ohci_hcd:usb7
    185: 16473094 0 IO-APIC-level uhci_hcd:usb1,
    ohci_hcd:usb6, skge, nvidia
    193: 0 0 IO-APIC-level uhci_hcd:usb2
    201: 3 0 IO-APIC-level ehci_hcd:usb4
    209: 77 0 IO-APIC-level ehci_hcd:usb5, bttv0
    217: 122690 0 IO-APIC-level Intel 82801DB-ICH4
    225: 3711236 0 IO-APIC-level saa7133[0], saa7133[0]
    NMI: 0 0
    LOC: 6135464 6135463
    ERR: 0
    MIS: 0
    ct@wimp:~$
    No clue what this all means. Off to tldp to read up on it.

    Get well!

  15. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:PIswj.3538$tW.1413@nlpi070.nbdc.sbc.com...
    > Moe Trin wrote:





    > the keyboard LEDs follow....
    >
    > LEDs don't respond. Numlock LED is on and it stays on when I press the
    > key. Ctrl+Alt+Backspace, F1, etc does nothing...
    > I've tried unplugging and plugging into a different USB port, plugging in
    > a different keyboard, plugging in a PS2 keyboard.
    > No joy...


    Are you sure your mythTV recordings continue when its in this state as you
    indicated earlier?
    It sounds like the hardware is locking up but it can't be if the recordings
    continue.
    Unless you can confirm the recordings do continue I would check the hardware
    carefully for things like loose heat sinks, cables, chips, etc. before
    delving into debugging the software. But then I am a hardware guy. ;-)

    >
    > btw, running Ubuntu 6.10 Gnome. It's a pretty esoteric box that I put
    > together 10 years ago. i850 chipset, 1GB of PC1066 Rambus RIMM. Hardware
    > might just be a little too flaky for Ubuntu.
    >
    >>...
    >>> No HDD activity, no network activity. Should have been streaming a
    >>> recording to the MythTV frontend but that playback froze. pan was
    >>> downloading some stuff and there's a 23 minute gap in that so it
    >>> stopped.

    >>
    >> That smells like a blocked interrupt. How did 'time of day' show?

    > The clock is (usually) not visible on the menubar when it locks. Be
    > interesting to see if it's still running.


    I think Moe means have a look in the logs and see if it is recording the
    time.. the display is likely to be frozen still even if the clock is
    running. From your description I don't expect there to be any log entries
    after the problem but its worth checking. Don't ask me how I have never seen
    mythTV.




  16. Re: Is this data really stored in the RAM?

    On 2008-02-22, clay wrote:
    > I came across an article on PC security and encryption
    > and found an interesting command.
    >
    > sudo strings /dev/mem | less
    >
    > grepped for password and found nothing so it doesn't appear to be a
    > security risk...


    I searched mine and found two of my passwords in there in plain text.
    The permissions on the file are
    crw-r----- 1 root kmem
    so I'm not worried, but it's interesting.

    --
    -Toby
    Add the word afiduluminag to the subject to circumvent my email filters.

  17. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >
    >
    > "clay" wrote in message
    > news:PIswj.3538$tW.1413@nlpi070.nbdc.sbc.com...
    >> Moe Trin wrote:

    >
    >
    >
    >
    >> the keyboard LEDs follow....
    >>
    >> LEDs don't respond. Numlock LED is on and it stays on when I press the
    >> key. Ctrl+Alt+Backspace, F1, etc does nothing...
    >> I've tried unplugging and plugging into a different USB port, plugging
    >> in a different keyboard, plugging in a PS2 keyboard.
    >> No joy...

    >
    > Are you sure your mythTV recordings continue when its in this state as
    > you indicated earlier?...


    Yep.
    MythTV (and Linux in general, it would seem) is not bothered by trivial
    things such as restarts.
    If it is recording a show and the computer is restarted it starts a new
    recording of the same program. It displays recording start and end times
    so I can see there were approx. two minutes missed between the two
    recordings.
    The box was locked up for at least 10 minutes while I tried different
    ways to get into it.
    pan was downloading some rarfiles during this. Approx, 30 seconds per
    rar. There was a 10 minute gap in the saved files so I can see pan
    stopped soon as it hung.

  18. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:GsCwj.3586$tW.835@nlpi070.nbdc.sbc.com...
    > dennis@home wrote:
    >>
    >>
    >> "clay" wrote in message
    >> news:PIswj.3538$tW.1413@nlpi070.nbdc.sbc.com...
    >>> Moe Trin wrote:

    >>
    >>
    >>
    >>
    >>> the keyboard LEDs follow....
    >>>
    >>> LEDs don't respond. Numlock LED is on and it stays on when I press the
    >>> key. Ctrl+Alt+Backspace, F1, etc does nothing...
    >>> I've tried unplugging and plugging into a different USB port, plugging
    >>> in a different keyboard, plugging in a PS2 keyboard.
    >>> No joy...

    >>
    >> Are you sure your mythTV recordings continue when its in this state as
    >> you indicated earlier?...

    >
    > Yep.
    > MythTV (and Linux in general, it would seem) is not bothered by trivial
    > things such as restarts.
    > If it is recording a show and the computer is restarted it starts a new
    > recording of the same program. It displays recording start and end times
    > so I can see there were approx. two minutes missed between the two
    > recordings.


    That wasn't what I meant. 8-(

    > The box was locked up for at least 10 minutes while I tried different ways
    > to get into it.
    > pan was downloading some rarfiles during this. Approx, 30 seconds per rar.
    > There was a 10 minute gap in the saved files so I can see pan stopped soon
    > as it hung.


    However I think that confirms it is probably a hardware problem.
    Time to re-seat all the removable bits and cables and check the fans are
    working.


  19. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >...
    >>>
    >>> Are you sure your mythTV recordings continue when its in this state
    >>> as you indicated earlier?...

    >>
    >> Yep.
    >> MythTV (and Linux in general, it would seem) is not bothered by
    >> trivial things such as restarts.
    >> If it is recording a show and the computer is restarted it starts a
    >> new recording of the same program. It displays recording start and end
    >> times so I can see there were approx. two minutes missed between the
    >> two recordings.

    >
    > That wasn't what I meant. 8-(


    You asked:

    > Are you sure your mythTV recordings continue when its in this state as you indicated earlier?
    > It sounds like the hardware is locking up but it can't be if the recordings continue.
    > Unless you can confirm the recordings do continue I would check the hardware carefully for things like loose heat sinks, cables, chips, etc. before delving into debugging the software. But then I am a hardware guy. ;-)


    If you didn't mean was I sure the recordings continued (Which I am sure
    of, and explained how I confirmed that... the computer was locked for
    more than ten minutes yet the only break in recording was two minutes
    prior to the restart. Roughly the length of time a restart takes.)
    Then I really don't understand your question...


  20. Re: Is this data really stored in the RAM?

    On Sun, 24 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >Moe Trin wrote:


    >> That's not nice. Is there any pattern of what you are doing when it
    >> locks up?

    >
    >No real pattern. Sometimes scheduling MythTV recordings, sometimes
    >editing recordings stored on this box or stored on the master.
    >Emailing, browsing the web...
    >It doesn't happen often, less than once a month.
    >When it does, the display is frozen, cursor stops blinking if it was,
    >and basically becomes a screenshot.


    Hmmm

    >> Does it normally respond to pings?

    >
    >When it's not locked up, it does.


    OK - no access via networking

    >> Normally, the first thing on a headed system that I'd check (all of
    >> my servers are headless, with no display or keyboard) is to poke the
    >> NumLock or ScrollLock key, and see if the keyboard LEDs follow....

    >
    >LEDs don't respond. Numlock LED is on and it stays on when I press the
    >key. Ctrl+Alt+Backspace, F1, etc does nothing...


    OK - that's sounding more and more like an IRQ block.

    >I've tried unplugging and plugging into a different USB port, plugging
    >in a different keyboard, plugging in a PS2 keyboard.


    Not that hardware...

    >No joy...
    >
    >btw, running Ubuntu 6.10 Gnome. It's a pretty esoteric box that I put
    >together 10 years ago. i850 chipset, 1GB of PC1066 Rambus RIMM. Hardware
    >might just be a little too flaky for Ubuntu.


    Shouldn't be.

    >> That smells like a blocked interrupt. How did 'time of day' show?


    >The clock is (usually) not visible on the menubar when it locks. Be
    >interesting to see if it's still running.


    I think you said it locked up for 23 minutes. Was there any thing in
    the logs in that period, or any file written during that period? Your
    previous post reporting this was

    Date: Sun, 24 Feb 2008 15:54:06 -0800

    As I write this, it's just coming up on 5:30 PM MST, and what I can do is
    to try using 'find' to see if anything was written around that time.

    [compton ~]$ date
    Mon Feb 25 17:26:18 MST 2008
    [compton ~]$ date --date="1470 minutes ago"
    Sun Feb 24 16:56:45 MST 2008
    [compton ~]$

    find / -mmin -1500 -mmin +1440 -exec ls -ld {} \;

    should find files and directories anywhere on the system that were
    modified 30 minutes either side of 24.5 hours (1470 minutes) ago. Adjust
    as required to get to the appropriate time.

    >> Yes, and I'd also think about watching /proc/interrupts, but that
    >> can be tedious. Are you running the system 24/7?

    >
    >It runs 24/7 as a slave on my MythTV system. No cron task today but it
    >gets a workout commflagging and transcoding recordings, memory intensive
    >stuff. I pile on an unrar job pretty much brings it to it's knees. Chugs
    >away though... usually.


    OK

    >ct@wimp:~$ cat /proc/interrupts
    > CPU0 CPU1
    > 0: 6135094 0 IO-APIC-edge timer
    > 5: 0 0 IO-APIC-edge MPU401 UART
    > 7: 0 0 IO-APIC-edge parport0
    > 8: 3 0 IO-APIC-edge rtc
    > 14: 638957 0 IO-APIC-edge ide0
    > 15: 4042908 0 IO-APIC-edge ide1
    >169: 1 0 IO-APIC-level acpi
    >177: 1124384 0 IO-APIC-level libata, ide2, uhci_hcd:usb3,

    ohci1394, ohci_hcd:usb7
    >185: 16473094 0 IO-APIC-level uhci_hcd:usb1,

    ohci_hcd:usb6, skge, nvidia
    >193: 0 0 IO-APIC-level uhci_hcd:usb2
    >201: 3 0 IO-APIC-level ehci_hcd:usb4
    >209: 77 0 IO-APIC-level ehci_hcd:usb5, bttv0
    >217: 122690 0 IO-APIC-level Intel 82801DB-ICH4
    >225: 3711236 0 IO-APIC-level saa7133[0], saa7133[0]
    >NMI: 0 0


    Holy Sh!t, something is rotten in Denmark! Look at IRQ 0. That's the
    system timer, which is normally running at 100, 500, or 1000 interrupts
    per second. Try manually running the command 'grep 0: /proc/interrupts'
    as close as you can to ten seconds apart. That will tell you which rate
    it's set at. Now come up with a reason why the second IDE controller
    is banging away at a rate ~2/3 as often, never mind why IRQ 185 is
    screaming away 2.7 times as fast as the timer. IRQ 225 is also on the
    high side (though I've no idea what that may be), and IRQ 14 (the
    primary IDE controller) is on the high side.

    Old guy

+ Reply to Thread
Page 1 of 2 1 2 LastLast