Virtualized Arch (VirtualBox) - System clock is wrong..,

In my Arch Linux VM, my system clock is either 7 hours slow or 17 hours fast (can't tell the date on it...how do I make Fluxbox display the date with the time?). This may be a problem with Arch but it most likely is a VirtualBox issue. How can I change the system clock on V-box (if that's the issue) or how can I fix Arch?
This may be a timezone issue. I live in the US, but I set "Canada/Eastern" as the timezone. Shouldn't matter because I'm in the Eastern time zone but in the interest of full disclosure, I thought I'd mention it.
EDIT: May or may not be important: I'm using Virtualbox OSE, not the proprietary edition.
Last edited by sajro (2008-03-21 13:37:56)

As far as i'm aware, clocks in virtual systems are always wrong. I don't think it's to do with arch (although changing UTC to localtime or vice versa in rc.conf might have some effect), more to do with the timing of the CPU or something being slightly off for virtual machines due to the virtual nature of the system.

Similar Messages

  • [SOLVED] System Clock Issues (Wrong UTC?)

    **RESOLVED -- SEE END FOR FIX
    Hello everyone.
    First off I'd like to say that I am thrilled to be here. I've been an Ubuntu user for a few months now, but decided that it was time to take a trip down the rabbit hole and see all that Linux had to offer--and to that end I switched to Arch. And I must say that I have nothing but positive things to say of it. The documentation on the Arch Wiki was phenomenal in helping me get started on the process, and the installation of it has proved to be a very enjoyable learning experience.
    With that said, I have run into a bit of a snag, and after perusing the documentation on the Wiki, as well as running a few Google searches and searches of this particular forum, am no closer to a solution that when I started, so here I am. The problem is with my clock.
    Okay, so I live in the Eastern United States, and as a result have my local time set as Eastern, and I have my hardware clock running UTC. Here is the problem. . . For whatever reason, the time displayed on my clock is five hours behind. Perplexed, I decided to see if I had set up my time zone info incorrectly and ran the "timedatectl status" command, and the results were really strange. A copy paste of the output is here:
          Local time: Thu, 2012-12-20 19:27:02 EST
      Universal time: Fri, 2012-12-21 00:27:02 UTC
            RTC time: Fri, 2012-12-21 00:27:02
            Timezone: America/New_York
          UTC offset: -0500
         NTP enabled: no
    NTP synchronized: no
    RTC in local TZ: no
          DST active: no
    Last DST change: EDT → EST, DST became inactive
                      Sun, 2012-11-04 01:59:59 EDT
                      Sun, 2012-11-04 01:00:00 EST
    Next DST change: EST → EDT, DST will become active
                      the clock will jump one hour forward
                      Sun, 2013-03-10 01:59:59 EST
                      Sun, 2013-03-10 03:00:00 EDT
    As you can see, the time zone is set correctly to America/New_York (originally US/Eastern, but I changed it to try and resolve the problem--to no effect, obviously). However here is where it gets strange. As I type this, it is 00:27 local time. My computer has decided to use the local time for UTC, and then subtracts five hours (as I live in UTC -5) to get the local time that it displays.
    I've tried rerunning the hwclock --systohc --utc command, to no avail.
    If anyone has any input as to why my computer is confusing UTC and local time, and any way I could fix it, I would greatly appreciate it.
    I could just change my timezone to UTC - 0, that would cause my system to display the right time (I think) but I'd rather actually fix the problem, instead of simply covering it up with a band aid, if it is possible.
    Thank you,
    Douglas
    EDIT:
    I probably should mention that the machines (I'm having this same problem on two different computers) are both running Arch Linux and Arch Linux alone, although one was originally a Windows 7 and the other a dual boot of Win 7 and Ubuntu.
    RESOLUTION (Thanks lhoffman):
    Install the network time protocol daemon. This will allow you to sync your system time over the internet.
    sudo pacman -S ntp
    Once installed, run the following command:
    ntpdate pool.ntp.org
    This will link your computer with the time servers of the NTP Pool Project. For me my clocks fixed themselves quickly after running the command. And that was it.
    After running this command and setting the system clock, run:
    hwclock -systohc      (thanks Scimmia)
    Otherwise the computer will mistake local time for UTC and subtract/add time based upon your timezone again upon reboot.
    Last edited by douglasr (2012-12-21 21:23:11)

    Scimmia wrote:Not exactly. The root of the problem is that your hardware clock is set to localtime. To change this, you need to update the system (software) clock, which ntpd already did for you. The timedatectl command would have just done that manually. Now that your system clock is correct, you need to write this to your hardware clock so that it is correct when you reboot. hwclock --systohc does that. If you don't run that command, the system will boot up thinking it's getting UTC from the hardware clock and will subtract 5 hours. Then, once ntpd runs, the time will skip ahead 5 hours. This will cause all kinds of issues.
    I fixed this on my system too. Thanks for the explanation.

  • Clock showing wrong hour even though I followed the Beginner's Guide

    Hey guys,
    So today I re-installed ArchLinux & Windows 7 on my laptop, here's how it works:
    SSD: ArchLinux x64
    HDD: Windows 7
    I mainly use Arch, and the few times I use Windows, I choose to boot from my HDD instead of my SSD, from the BIOS.
    Technically, it's not a dual boot I guess, so I shouldn't be affected by these manipulations
    The time showed in my BIOS is correct.
    The time showed by Windows 7 is correct.
    The time showed in ArchLinux is however wrong, it's two hours late.
    Following the Beginner's Guide I've run these command without success:
    hwclock --systohc --utc
    If any of you has any suggestions...
    Thanks :]

    My apologies. I thought that this particular problem between Windows and Linux was caused by Windows somehow overwriting Linux settings, and since in my case they are in different physical drives, I thought I wasn't concerned.
    Anyway, since I've read somewhere in the wiki that localtime should be avoided, I successfully did the manipulation do set Windows 7 in UTC.
    I've then updated the hardware clock and system clock time, but it didn't change a thing.
    I'm going to try the manipulations provided by your link luvfree, thanks
    I'll keep you posted, thanks to all of you, and again, my apologies for my wrong asumptions
    EDIT: APPARENTLY IT'S SOLVED:
    I had to boot into Linux, and set the time manually with:
    # date +%T -s "10:13:13"
    Then run:
    hwclock --systohc --utc
    Next boot, the time value were correct int both Linux, AND Windows
    Thanks to all of you, I'll try to think more next time
    Last edited by Lowra (2012-09-29 08:14:01)

  • [SOLVED] Arch restores hw clock to time before turned off on boot

    Subject of this thread pretty much sums this up.
    When I boot my computer into Arch, system clock is set to the time when I turned my computer off. I have ntp installed, but it is not running as deamon. I just have cron job that calls ntpdate once a day which was working fine until now.
    So here is the example situation:
    It is now 23:47. I have correct time set on my PC. I turn off Arch. I wait five minutes. Then I start my PC again. Before booting into Arch I check time in bios and it is as it should be. I boot into Arch and my time is 5 minutes late.
    I also have Ubuntu on the same machine. It does correct time on boot, so I removed startup permissions of ntp. Now it does not correct time on boot anymore. But I can turn off my computer and boot into Ubuntu just fine, no problem with time. So I am pretty sure this is Arch messing up.
    Anyone has idea what this can be? I bought new motherboard battery just to be sure. Did not help obviously.
    Last edited by Raqua (2010-02-17 08:17:51)

    Probably the time adjustment has been wrongly initialized. Delete /var/lib/hwclock/adjtime, set your hardware clock properly and then reboot. This will re-initialize the adjtime file with proper settings.
    Helps in most cases. Otherwise just report back.
    Last edited by bernarcher (2010-02-16 23:51:40)

  • HOWTO: Repairing a headless Arch Linux system that fails to boot

    The scenario...
    I have a "headless" (no monitor or input peripherals) Arch Linux computer that is connected to a local network via a wireless adapter, and accessed from other computers via SSH.
    Earlier today I accidentally broke its kernel so it did not boot anymore.
    Idea: Temporarily connect a monitor to the computer, boot from a live CD (like the Arch Linux install CD), then chroot into the system and fix it.
    Problem: I didn't have a compatible monitor at hand.
    Idea: Log in to the live CD session from another computer via SSH.
    Problem: The live CD can't auto-configure the headless computer's wireless connection, and setting it up manually while working "blind" would be a major hassle. A direct LAN connection to the router wasn't available either.
    Idea: Connect directly with a laptop via an Ethernet cable, and then use SSH from the laptop => This solution worked for me!
    If you find yourself in a similar situation, you can follow this tutorial which describes the solution that worked for me in detail...
    You need:
    a copy of the Arch Linux install CD (I used the 2013-05-01 version)
    an Ethernet cable
    a keyboard (might be dispensable, with additional preparation)
    a functional Arch Linux laptop (or other computer within physical range)
    Step 1) Prepare the live CD...
    I used the plain Arch Linux install iso, burnt to CD.
    By creating a carefully customized version of the live CD using Archiso, you might be able to eliminate the need for steps 2 and 4 - however that's not covered in this tutorial.
    Step 2) Prepare the laptop...
    The laptop needs to be configured in such a way, that the live CD's attempt to automatically establish an Ethernet connection with it will succeed:
    a) IP address
    In my case, the Laptop's wireless adapter had an IP address in the range 192.168.1.*, connecting it to the local network and Internet via the central router 192.168.1.1.
    The Ethernet connection between the laptop and the headless computer becomes a separate mini-network, for which I decided to use IP addresses in the range 192.168.0.* (note the different third number). Specifically, I set the IP address of my laptop's Ethernet card to 192.168.0.1. You can do this by running the following as root (replace "eth0" with the name of your Ethernet interface):
    ip link set eth0 up
    ip addr add 192.168.0.1/24 dev eth0
    b) IP forwarding (optional)
    While we're at it, we might as well enable IP forwarding, so that the live CD session on the headless computer will be able to directly use the laptop's outgoing Internet connection (which will make it much more convenient to install/upgrade packages during the repair session). To enable this, run the following as root (replace "eth0" and "wlan0" with the names of your laptop's Ethernet and wireless interfaces, respectively):
    iptables --table nat --append POSTROUTING --out-interface wlan0 -j MASQUERADE
    iptables --append FORWARD --in-interface eth0 -j ACCEPT
    sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
    c) DHCP
    The live CD will assume there's a router on the other side of the Ethernet link, and ask for an IP address via DHCP. So all we need to do, is run a dhcp server on the Laptop that will answer this request. It's surprisingly easy: Just install the package dnsmasq, and put the following in the file /etc/dnsmasq.conf (again replacing "eth0" as appropriate):
    interface=eth0
    dhcp-range=192.168.0.2,192.168.0.2
    By setting the start & end values of dhcp-range to the same IP address, we enforce that this specific IP address will be used by the live CD on the headless computer.
    Then start the daemon by running the following as root:
    systemctl start dnsmasq.service
    Step 3) Connect everything and boot up the live CD...
    Connect the laptop and the headless computer via the Ethernet cable.
    Connect the external keyboard to the headless computer.
    Then put the Arch Linux install CD into the headless computer's drive, and boot. Wait a minute or so to give the CD time to load its boot menu (you should hear the CD drive spin up and settle down again). Then hit ENTER on the connected keyboard, to activate the default menu choice (which will boot straight to a live Arch Linux session with root privileges).
    You can check whether it booted up and successfully initialized the Ethernet connection, by ping'ing the IP address that was specified in step 2c) from the laptop:
    ping -c3 192.168.0.2
    Step 4) Start the SSH server...
    Unfortunately, the Arch Linux install CD doesn't automatically start its SSH server, and also it uses a randomized root password. To make SSH connections possible, you will have to use the connected keyboard to type in some stuff "blindly" (but it's simple enough):
    type "passwd" (without the quotes)
    type in a new password of your choice
    press ENTER
    type in the same password again
    press ENTER
    type "systemctl start sshd" (without the quotes)
    press ENTER
    Step 5) Connect from the laptop via SSH...
    Now you can open an SSH connection, by executing the following on the laptop (when it asks for the password, enter the one you chose in step 4):
    ssh [email protected]
    Step 6) Profit!
    Within this SSH shell on the laptop, you can now do whatever you would usually do to fix an Arch Linux system from a live CD.
    You'll probably want to chroot into your Arch root partition, which is very easy thanks to the arch-chroot tool that is included on the live CD (replace "/dev/sda3" with the name of the headless computer's root partition):
    mount /dev/sda3 /mnt
    arch-chroot /mnt
    If you set up IP forwarding as described in step 2b), then Internet access should magically work in this shell without any further configuration, so you can freely use pacman etc. inside the chroot.
    Enjoy!
    Last edited by sas (2013-07-26 22:17:03)

    It is definitely able to recognize the USB and DVDs as separate drives; it gives the option of booting from USB, and it gives the memory capacity of the USB drive I used as a live USB, and the memory used for the live CD.  But when it comes time to actually boot, something is going wrong.
    I would suspect it is a problem with the BIOS, if not for the fact that I had a similar issue on my previous system, which used a completely different motherboard.  If it is the same issue, it would either have to be a problem with the DVD drive (although I don't know why it would be against loading some live CDs but not others) or perhaps the way I created the live CDs.  Although, again, I don't understand why the Linux Mint 32-bit DVD would work fine, while both 64-bit DVDs would not.
    I will try using a different DVD drive to boot the DVDs, and if that does not work, I'll try creating a new Arch live CD to see if I can resolve the issue.  But if anyone has any ideas, it would still be greatly appreciated.

  • Finder has got out of sync with system clock?

    For some reason, the system clock is reading the correct time, but the times indicated in Finder for "Date Modified" for every file or app are all wrong.
    For example, at 11:45PM (as indicated by the clock in the menu bar) I installed OnyX for the first time, but when I look at the newly-installed app itself in the Applications folder in Finder, in the Date Modified column it says "Today 11:23PM". Also, various different apps and files have identical Date Modified times - several have 12:12PM, several have 8:08AM, and many have 4:16PM.
    Two more confirmers that there's a problem - I just created a new folder at 12:35AM, and immediately went to look at it in the Finder - its Date Modified is "Today 12:00AM". And when I start up Plex, its own on-screen clock says "12:00AM" when the clock in the menu bar says 12:40AM.
    I've zapped the PRAM and forced a Spotlight reindex, but they've made no difference. Any suggestions?

    Is the correct Time Zone set for your region of use?
    Is the Time set to be coordinated with a network time server?
    These are two basic things that could go wrong. There may
    be others. I'm not sure at this moment what they may be.
    You may have to see if your use of OnyX has somehow
    changed the basic system settings; or maybe you did
    not use the section most likely in OnyX to be helpful.
    Or something else is acting up.
    (Looking into my Date Time panel now has me wondering,
    since I never look into there. It just works, usually!)
    Good luck & happy computing!

  • [SOLVED] System clock refuses to adopt my timezone

    (Running ArchLinux in VMWare)
    I'm trying to set my system clock to Europe/Lisbon unsuccessfully. I followed these steps:
    Step 1. (rc.conf)
    HARDWARECLOCK="UTC"
    TIMEZONE="Europe/Lisbon"
    Step 2. (localtime)
    $ rm /etc/localtime
    $ ln -sf /us/share/zoneinfo/Europe/Lisbon /etc/localtime
    Step 3. (reboot)
    Result:
    marfig@archway ~ $ date
    Fri Aug 6 15:27:26 WEST 2010
    marfig@archway ~ $ hwclock
    Fri 06 Aug 2010 03:27:31 PM WEST -0.000409 seconds
    Is there something wrong with /us/share/zoneinfo/Europe/Lisbon?
    Last edited by marfig (2010-08-06 14:49:17)

    marfig wrote:
    No. The time is correct. The timezone isn't. Why is it displaying Western time? (WEST)
    EDIT: gah! I'm so stupid. the simple fact I wrote this prompted me to search 'west timezone' in google. This Western European Time Summer Time. The timezone is correct and I'm a fool. So sorry for this useless thread.
    You should add this to the Try This thread called the "dumbest mistake you made"
    https://bbs.archlinux.org/viewtopic.php?id=11728
    Last edited by Inxsible (2010-08-06 14:51:18)

  • Hyper-v replication Error Hyper-V received a digital certificate that is not valid from the Replica server 'burstingreplica'. Error: A required certificate is not within its validity period when verifying against the current system clock or the timestamp"

    Hi,
    When trying to initiate hyper-v replication from the main server i'm getting this error in the event logs.
    Hyper-V failed to enable replication for virtual machine 'RECADemo': A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. (0x800B0101). (Virtual Machine ID 561591B6-567C-...)--I'm using certificate based auth and cert is installed/recognized on both machines.Please help.Thanks,Jaffer
    Jaf

    Hi,
    This error occurs because the Microsoft Certificate Trust List Publisher certificate expired. A copy of the CTL with an expired signing certificate exists in the CryptnetUrlCache
    folder. Please try to renew the Trust List Publisher certificate.
    The related KB:
    Event ID 4107 or Event ID 11 is logged in the Application log in Windows and in Windows Server
    http://support.microsoft.com/kb/2328240
    How to Renew the Site Server Signing Certificate (Microsoft Certificate Services)
    http://blogs.technet.com/b/configmgrteam/archive/2009/02/11/how-to-renew-the-site-server-signing-certificate-microsoft-certificate-services.aspx
    Manage Trusted Publishers
    http://technet.microsoft.com/en-us/library/cc733026.aspx
    Hope this helps.
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • My system clock

    after I flashed my bios the system clock in the bios reset to 0:00:00 so I set them to the right time and rebooted my computer. After I did that I started to notice that the clock in win98 SE was losing minutes compared to the clock on my cable box. I didn't think anything of it and turned off my computer and went to bed. I woke up today and booted up my computer and win98 still said the time yesterday when I had shut it off and still had yesterdays date. My question is what is wrong or what am I doing wrong, and could this be stopping me from installing winXP or 2000 on my system?
    Specs:
    AthlonXP 2000+
    Kingston 256MB DDR PC2100
    Samsung 60GB HDD
    48X CDRW
    16X DVD
    ATI Radeon 9000 Pro
       Thanks for any help.

    Quote
    I pulled out my CMOS battery and checked the connection it seems fine, I can't check the volts for I don't have a meter. It is still doing it, is there a possability the battery could be bad and I should replace it? Also would this stop me from installing WinXP or 2000?
    with a dc volt meter it is hard to get an accurate reading of the bat......what is the pc health giving for vbat....for an extended period?
    This should not stop installs of the os I do not think.
    I would double check you pin assignments for you other stuff.......like power led and reset....
    Hav you tried installing your os with just the minimum components......where does it get to in installation?

  • Arch64 and system clock havoc

    Hello,
    I recently upgraded my HP DV6140 laptop to Arch64. I used to use 32bit, but found myself impressed with how smooth things have become with the 64bit version. However, I soon found out that 1/4 of the time I boot up, I get a hard crash. This is always at Configuring System Clock in the boot process. Also, about 3/4 of the time when I change the date/time I get a hard crash. Annoying as hell, being that I can't use NTP to sync my time/date settings without frequent crashing. Any ideas on this? It was never a problem with 32bit Arch.
    I've tried kernel 2.6.19, and 2.6.17beyond and both result in the same problem. I also tried tinkering with localtime and UTC in the rc.conf file with no luck on fixing this.

    AndyRTR wrote:
    I have ntpd running as server and use it as client on two systems without any problem. Do you have entries in any logfile when it crashes?
    I only remember that the rtc kernel module was tricky when it was built as module. That's why we had put it directly into the kernel in early 2.6.14 days.
    As far as the logs go I could not find anything out of the ordinary. If you would like you can have a look at my logs, I uploaded it to:
    http://jskier.com/linux/everything.log

  • Configuring System Clock Failed

    Hi I am new to Arch, but most things are going great.  This is what happened.  I have spent the last day setting up arch and everything has been going smoothly.  Recently it did a filesystem check and I had to manually fix some things on my root hard drive.  After that system clock fails to configure and the gnome panel clock crashes every time I try and load it. This is what I get from the buggy buddy or whatever
    ----------- .xsession-errors ---------------------
    interface  wlan0   down . Waking up device ...
    Looking for known wireless networks ...
    seahorse nautilus module initialized
    ** (nautilus:3479): WARNING **: Unable to add monitor: Not supported
    Unable to open desktop file evolution.desktop for panel launcher
    profile started : ender_001601842972 0
    compiz (core) - Error: no 'text' plugin with ABI version '20080421' loaded
    compiz (scaleaddon) - Warn: No compatible text plugin found.
    Network connected succesfully. ExitCode = 0
    Unable to open desktop file evolution.desktop for panel launcher
    I haven't found anything on this really...any help getting that working again?   Thanks

    Well I fixed it so here it is... sudo pacman -S gnome-panel.  Just reinstalled that bad boy and my clock works a treat.  I still have to mess with my rc.conf and see if i did something that would get me that boot script failing on system clock, but my clock works fine and so does my NTP update.

  • Install changes system clock

    how come when i install arch, and then boot into windows later, my system clock is changed to like 8 hours ago.  has this happened to anyone before?

    And what time is it really ?
    What I would do now : decide for yourself if you want the CMOS clock in localtime or not. Your decision will probably depend on your Windows system. If you have WIndows98 (first edition) or earlier, you have no choice: CMOS should be localtime. If you have Win98SE or later then carefully check in your Windows system how you set it up. It *usually* wants it in localtime, but it can handle UTC, therefore check your configuration.
    Now, you know how you want your CMOS/BIOS clock to be.
    Now boot into Arch and edit /etc/rc.conf accordingly. Note, however that your TIMEZONE is incorrect. You probably want something like
    TIMEZONE=America/New_York
    TIMEZONE=EST
    Note, that the first automatically switches between daylight savings time, whereas the second does not necessarily. The value you give to TIMEZONE has to actually exist as a file in /usr/share/zoneinfo/ (I.e. no matter weather you live in Boston, D.C., Miami, Atlanta, Philladelphia you always choose America/New_York) !
    Now that you have edited /etc/rc.conf correctly, I would boot into the BIOS and set the CMOS clock there correctly.
    EDIT: links to 2 previous threads about this topic :
    http://bbs.archlinux.org/viewtopic.php?t=2198
    http://bbs.archlinux.org/viewtopic.php?t=830

  • Is Mail.app one of the "erratic" behavior apps with a reset system clock?

    I am hoping someone can help with a fine detail of mail.app (v2.1.3) behavior.
    I had an incident where an iMac sent out 200+ smtp hits a minute and was tossed of the network for presumed zombie spaming.
    I think I have actually tracked the problem to an unfortunate conjunction of circumstances that is actually innocent (if still annoying)
    Let me set up the story:
    1. This is a common use computer, so Mail is not configured (except that it is --I'll get to that in a moment) and
    2. Safari will invoke Mail when you click on an "email link"
    Mostly everyone just quits mail if they goof and click an email link.
    BUT some time ago at least one person invoked Mail and composed a message. This message, naturally, remained in the outbox ever since. That person learned that they can't send email that way, so ever since they just cmd-Q Mail.
    BUT Before this person learned, they walked through the mail-config and told mail to try hitting smtp.mac.com:"nonExistantUser".
    So that covers the lead-up. Two days ago, mail was invoked via a Safari link, BUT it wasn't quit, it was sent to the background.
    Where it undoubtedly tried to send the outbox repeatedly until it was kicked off the network.
    Here is what I don't understand:
    Under this scenario of a mis-configured .mac address, will mail repeatedly try and fail to smtp at the maximum possible rate?
    OR
    Is the one other factor I am about to describe responsible?
    The one other factor:
    The clock battery is dead and there was a power failure at 4am that day.
    The system clock reset to 1969.
    Of course, nobody reset it.
    Is mail.app one of the apps that the finder message warns "may behave erratically"?
    (a GROSS simplification) does it have a bit of code like:
    1 check time-of-last-send-mail-attempt
    check newest-item-in-outbox
    if newest-item more recent then last-send-attempt
    do send-mail and record time-of-last-send-mail-attempt
    and go to 1
    else wait X minutes and go to 1
    which, if the clock was mis-set to 1969 would always record a last-send-attempt prior to anything in the outbox and trigger a send loop.
    Does anyone know if either Mail is tenacious about sending to a bad .mac address, or gets ridiculous under this circumstance for bad-clock-set?
    Marc

    I am hoping someone can help with a fine detail of mail.app (v2.1.3) behavior.
    I had an incident where an iMac sent out 200+ smtp hits a minute and was tossed of the network for presumed zombie spaming.
    I think I have actually tracked the problem to an unfortunate conjunction of circumstances that is actually innocent (if still annoying)
    Let me set up the story:
    1. This is a common use computer, so Mail is not configured (except that it is --I'll get to that in a moment) and
    2. Safari will invoke Mail when you click on an "email link"
    Mostly everyone just quits mail if they goof and click an email link.
    BUT some time ago at least one person invoked Mail and composed a message. This message, naturally, remained in the outbox ever since. That person learned that they can't send email that way, so ever since they just cmd-Q Mail.
    BUT Before this person learned, they walked through the mail-config and told mail to try hitting smtp.mac.com:"nonExistantUser".
    So that covers the lead-up. Two days ago, mail was invoked via a Safari link, BUT it wasn't quit, it was sent to the background.
    Where it undoubtedly tried to send the outbox repeatedly until it was kicked off the network.
    Here is what I don't understand:
    Under this scenario of a mis-configured .mac address, will mail repeatedly try and fail to smtp at the maximum possible rate?
    OR
    Is the one other factor I am about to describe responsible?
    The one other factor:
    The clock battery is dead and there was a power failure at 4am that day.
    The system clock reset to 1969.
    Of course, nobody reset it.
    Is mail.app one of the apps that the finder message warns "may behave erratically"?
    (a GROSS simplification) does it have a bit of code like:
    1 check time-of-last-send-mail-attempt
    check newest-item-in-outbox
    if newest-item more recent then last-send-attempt
    do send-mail and record time-of-last-send-mail-attempt
    and go to 1
    else wait X minutes and go to 1
    which, if the clock was mis-set to 1969 would always record a last-send-attempt prior to anything in the outbox and trigger a send loop.
    Does anyone know if either Mail is tenacious about sending to a bad .mac address, or gets ridiculous under this circumstance for bad-clock-set?
    Marc

  • ICal, Mail and Finder times all stuck since upgrade!  System clock O.K.

    Very strange problem:
    All of my calendar event times (in iCal), email message receipt times (in Mail), and file modification/creation times (in Finder) are listed as some time between 7:00-7:59 AM or PM, regardless of time of day! My system clock (as it appears in the menu bar) is fine!
    More details:
    iCal: the events still look like they're at the right times, i.e. the blocks are in the right places, with the correct spacing, etc etc, they are just labeled with times between 7:00-7:59 AM/PM. Similarly, alarms go off at the correct time. Also, in the day or week listing, the column on the left which is supposed to show times instead just says "Sat" for all times, except "Noon" (at noon).
    This is continuous since upgrading to snow leopard a couple weeks ago. Seemingly no other problems besides this.
    I don't know much about the OS, but I don't understand how the system clock (in the menu bar) could be fine, but every other sign of time-keeping is completely off. I just its just something about the labeling of times, instead of the actual record of them?!
    I have screen shots of the problems if that might help clarify (apparently I can't attach them however).
    Thanks for your help!

    Hi,
    Any solutions to your problems?
    Just found my Mom has the same 'time stuck' problem (iMac OS X 10.6.7) Finder 'Date Modified' is stuck at 2/14/2011. Also, the Time/Date displays correctly on the Menu bar but when click on it, the drop down menu shows a gray out 2/14/2011, etc.
    Much appreciated of any help. Thx.
    -MasterMoo

  • Firefox 3.6.13 would not load under xp on acer computer. deleted in and downloaded version 4, but still does not load, just hangs system. what is wrong?

    a couple weeks ago, firefox stopped loading (just hung system) on my acer computer running windows xp. I deleted firefox and downloaded versin 4.0.1. But, the same thing is happening. it starts to load but then stops responding and hangs the system. what is wrong?

    I also have this problem and it just started in the last week or so. It seems to be dependent on my home network and the problem only exists with firefox. I have used chrome and IE8 with no issues. I can verify tomorrow that it only exists in my network but one thing I was able to test is that the problem exists even on my linux boot. I am totally dumbfounded with this problem and I can't find anything that will allow the gmail page to load. All other pages I have tried load fine, all be it a little slower than normal but they load. If anyone knows of a difference between firefox and all other browsers on how it goes through the router I would appreciate the info cause I don't know of any differences.

Maybe you are looking for