uptime

Argentum said:
I think I have discovered the root cause of FreeBSD unpopularity:
Code: 
~> uptime
 8:30PM  up 247 days,  3:38, 6 users, load averages: 0.90, 0.96, 0.93

Nothing really happens...

Code: 
  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 2635 root         17  20    0  2082M  1922M kqread   6 5213.0  56.71% bhyve
 1707 root         17  20    0  2082M  1908M kqread   2 245.5H   1.37% bhyve
19103 root         13  20    0  2073M  1781M kqread   2 201:57   0.53% bhyve
 2409 root         13  20    0  2073M  1791M kqread   6  46.1H   0.44% bhyve

This is not any record, this is just an average...
Click to expand...

:) A NUC with Arch:
Bash: 
% uptime
 19:06:34 up 175 days, 6 min,  1 user,  load average: 0.39, 0.41, 0.38
 
Code: 
root@mowa219-gjp4-8570p-freebsd:~ # bectl mount n249988-2c614481fd5-a /tmp/cooee
Successfully mounted n249988-2c614481fd5-a at /tmp/cooee
root@mowa219-gjp4-8570p-freebsd:~ # chroot /tmp/cooee
root@mowa219-gjp4-8570p-freebsd:/ # ls /usr/home
root@mowa219-gjp4-8570p-freebsd:/ # ls /usr/local
FreeBSD_ARM64                   llvm10                          openoffice-4.2.1602022694
GNUstep                         llvm11                          openoffice-4.2.1619649022
ICAClient                       llvm12                          openssl
VirtualBox                      man                             poudriere
bin                             mono                            sbin
etc                             openjdk11                       share
false                           openjdk11-jre                   steam-utils
furybsd                         openjdk16                       true
include                         openjdk8                        var
lib                             openjfx14                       wine-proton
lib32                           openoffice-4.1.6                www
libdata                         openoffice-4.2.1579913986       x86_64-portbld-freebsd14.0
libexec                         openoffice-4.2.1589199787
root@mowa219-gjp4-8570p-freebsd:/ # exit
exit
root@mowa219-gjp4-8570p-freebsd:~ # bectl umount n249988-2c614481fd5-a
root@mowa219-gjp4-8570p-freebsd:~ # ls /usr/local
FreeBSD_ARM64                   llvm10                          openoffice-4.2.1602022694
GNUstep                         llvm11                          openoffice-4.2.1619649022
ICAClient                       llvm12                          openssl
VirtualBox                      man                             poudriere
bin                             mono                            sbin
etc                             openjdk11                       share
false                           openjdk11-jre                   steam-utils
furybsd                         openjdk16                       true
include                         openjdk8                        var
lib                             openjfx14                       wine-proton
lib32                           openoffice-4.1.6                www
libdata                         openoffice-4.2.1579913986       x86_64-portbld-freebsd14.0
libexec                         openoffice-4.2.1589199787
root@mowa219-gjp4-8570p-freebsd:~ #
Thanks mer
 
I'm theoretically a fan of rebooting often. That's simply the admission that no software (not even FreeBSD) is perfect, and everything has the risk of small resource leaks.

The problem with that theory is that my FreeBSD home server is also the network gateway. And if I reboot, the network will be out for maybe 2 or 3 minutes. My wife is a morning person, and gets up way earlier than I do. So when I get up is not a good time to reboot, she's probably busy doing work, or at least relying on her cellphone etc. functioning. On the other hand, our college-age son loves playing computer games with his friends late at night (and he does not get up early). So the time when I either reboot or run freebsd-update is usually a weekend morning, when my wife isn't working (she might be shopping, doing gardening), and our son is still asleep. So a typical uptime for my machine is a week or two. If it reaches a month, that means I've been too busy to check for updates and quickly reboot.

The upper limit is set by SSL certificates: Those need to be renewed every 3 months, and after that the web server needs to be restarted. I think it's silly to restart a major service and leave the rest running (you're disrupting one service, may as well do all of them), so I always use a reboot at that time.
 
mark_j said:
That's your Microsoft training kicking in. :D
Click to expand...
I'm completely with SirDice on his response to that. Generally, with Windows systems, I am reboot-happy, only because a reboot helps the metal clear its throat (metaphorically speaking). Sometimes, it can be difficult to reboot a machine, because it's in the middle of something important that needs to complete first. But avoiding a reboot just for the heck of it???
astyle said:
UNIX is not a religion, buddy.??‍♂️
Click to expand...
Neither is Microsoft. Just reboot whenever you see the need. If it's difficult to safely reboot a machine - consider a different approach to the service the server is providing.
 
Argentum said:
My personal server uptime record with FreeBSD is over 1000 days.
Click to expand...
That's pretty impressive for a desktop. What kind of laptop is it?

Oh, that was at a data-center... I was talking about desktop uptime. I rebooted this one yesterday.

When I decided to use one of the Thinkpad W520's I had been using as a general purpose FreeBSD desktop as my multimedia machine (I do more than just listen to .mp3's on it) I pulled the Ethernet cord from it and could plug it back in now and go online. For an update.

I never turn off gkrellm2, urxvt, xfe or audacious from boot till shutdown and can leave Gimp open for days. I have a bamboo cutting board I got a Walmart that is the perfect size to set it on and not block the vent if I hold it on my lap and do graphic work. Which is most relaxing while listening to music in the recliner.

With a current total of 13,666 songs and beaucoup movies on USB I'm in the Halloween spirit today watching some Coffin Joe and listening to music. I have Gimp open for the shot and that's shown running at full load for it at 181 days:

Dark_Ness13666.jpg
 
Trihexagonal said:
I have a bamboo cutting board I got a Walmart that is the perfect size to set it on and not block the vent if I hold it on my lap and do graphic work. Which is most relaxing while listening to music in the recliner.
Click to expand...
Perfect laptop to take to a ski resort and do your Gimp work outside the chalet: :P just hold it on your lap to keep warm ;)
1634833338731.jpeg
 
That shows 57C so that's not hot. This one is showing 57C, too.
 
Trihexagonal said:
That's pretty impressive for a desktop. What kind of laptop is it?

Oh, that was at a data-center... I was talking about desktop uptime. I rebooted this one yesterday.

When I decided to use one of the Thinkpad W520's I had been using as a general purpose FreeBSD desktop as my multimedia machine (I do more than just listen to .mp3's on it) I pulled the Ethernet cord from it and could plug it back in now and go online. For an update.

I never turn off gkrellm2, urxvt, xfe or audacious from boot till shutdown and can leave Gimp open for days. I have a bamboo cutting board I got a Walmart that is the perfect size to set it on and not block the vent if I hold it on my lap and do graphic work. Which is most relaxing while listening to music in the recliner.

With a current total of 13,666 songs and beaucoup movies on USB I'm in the Halloween spirit today watching some Coffin Joe and listening to music. I have Gimp open for the shot and that's shown running at full load for it at 181 days:

View attachment 11785
Click to expand...
As an off-topic, there's a bar that I've used to go in São Paulo/BR were the owner was Mojica's son-in-law.
 
astyle said:
Making me jealous. What's the brand of those power supplies? I swear by EVGA.
Click to expand...
Do not remember. It was few years ago when the hardware got retired. It was 2U rack mount unit. I built it myself, but this happened 10 years before that. From a barebone. I think it was Gigabyte brand.
 
OpenVMS clusters are truly a thing of beauty and they've had them for decades. Their galaxies are/were rather groundbreaking.
 
With modern VMS, is it still true that every machine has to be rebooted at least once per year?

If I remember right, I think the reason was that the hardware clock in the VAX only stored month, day, hour, minute second, but didn't know what year it was. For that reason, the hardware clock was called the TOY clock: Time Of Year. The year is stored on the boot disk, but for some reason, that storage is updated only when you boot. So if you don't reboot for over a year, on the next boot time will go backwards by one year.

Now, that does not affect a VAXcluster, as every single host in the cluster has to reboot, but seen from the outside, the cluster remains perfectly operational.

There is a lot of hardware goodness that has been sacrificed on the altar of commodity hardware. For example, on PA-RISC HP-UX machines, you could lose a CPU (physical failure of the processor chip), and the machine would not shut down. Happened to us once: We noticed that we didn't get any mail for a day, and discovered that the sendmail master process has crashed. This made no sense to us, since sendmail was absolutely reliable (duh, obviously, it is an incredibly well engineered piece of software). Investigation of the log files showed that sendmail was executing exactly the moment that the hardware supervisor detected a failure of one CPU, and powered down that CPU. The only visible effect was that the process that had been running on the failing CPU gets aborted. Our machine kept running as a 3-way SMP, but the sendmail process did not get automatically restarted. No problem, we manually started it, ordered a spare CPU from field service. A few days later, at a convenient time, we powered the machine down, replaced the CPU, and brought it back up.

On IBM mainframes, you can do a lot of hardware repairs without shutting the machine down, like replace memory, CPU, busses, disk interfaces, and so on. Everything is redundant, and components can be individually disabled and powered down while the machine itself keeps running. I think the Z series mainframes are the last computer on which such a thing is still possible. The same is true of high-end disk arrays (Shark, Symmetrix, Hitachi).
 
ralphbsz said:
On IBM mainframes, you can do a lot of hardware repairs without shutting the machine down, like replace memory, CPU, busses, disk interfaces, and so on. Everything is redundant, and components can be individually disabled and powered down while the machine itself keeps running. I think the Z series mainframes are the last computer on which such a thing is still possible. The same is true of high-end disk arrays (Shark, Symmetrix, Hitachi).
Click to expand...

Telecom switches too. Shut down half the machine and everything else keeps working. Swap out hardware, apply patches, test, change your mind and roll back. Amazing stuff.
 
ralphbsz said:
With modern VMS, is it still true that every machine has to be rebooted at least once per year?
Click to expand...
Never in my experience.
It could if a patch kit was to be applied that required a reboot, but then a rolling reboot around the cluster would ensure it was never down.

ralphbsz said:
If I remember right, I think the reason was that the hardware clock in the VAX only stored month, day, hour, minute second, but didn't know what year it was. For that reason, the hardware clock was called the TOY clock: Time Of Year. The year is stored on the boot disk, but for some reason, that storage is updated only when you boot. So if you don't reboot for over a year, on the next boot time will go backwards by one year.
Click to expand...

Yes, you're correct it does not store a date as something like a unixtime, but you're not really correct.
I think the TOY (battery backed) stored around 500 or 600 days before it looped back.

The VAX (OpenVMS) stores the date in SYS$SYSTEM:SYS.EXE and uses it plus the TOY value to set $GQ_SYSTIME. The GQ_SYSTIME is the interval clock and it's just updated by an interrupt (which priority level I cannot recall). I don't believe the TOY is ever used again while the system is running. This means the time would not move forward if it was powered off for those 500/600 days, but it would not go backwards. Regardless, on reboot it would ask you to set the time anyway. It would never go backwards while running nor require a reboot to reset it (SET TIME can be run at any time).

The time can skew, of course, if the power supply to the box is not 60Hz.

I think VAX admins used to run set time periodically to reset the time using the TOY, but I am not sure if that's correct or not.

Of course, modern OpenVMS has had access to DTSS off decnet as well as ntp like all unix-like systems. Before the advent of ntp on OpenVMS, DTSS was the main time synchronisation across a cluster (as well as the cluster protocol itself).

Whether you keep an expensive piece of hardware powered off for a year I leave for debate to all the accountants.
 
I came across this site a while ago: https://www.reddit.com/r/uptimeporn/ Looks like long uptimes can be become
some sort of religion for some people.

For myself. If I make a change to my box or have a bit of a bigger upgrade I reboot. If something than looks not right
I can fix it on the spot. That's better than scratching my head a couple of month later and try to remember what
I have done.
 
Perhaps uptime became a religion because often these 'ancient' operating systems took a very long time to reboot. Some even broke upon reboot because some disk started out of order.
Nowadays hardware is so much more resilient.
If it wasn't then endless reboot to install the latest windows would surely blow the machine up.;)
 
mark_j said:
Perhaps uptime became a religion because often these 'ancient' operating systems took a very long time to reboot. Some even broke upon reboot because some disk started out of order.
Nowadays hardware is so much more resilient.
Click to expand...
With servers I have been in a situation where the physical access to the machine has been difficult and limited (drive to the DC, find the people with access). In several cases no KVM device connected, perhaps even not available. That means every reboot should be 100% sure. In such a situation one naturally does not want to reboot when the system is working and does its job...

Today I have one such box running:
Code: 
$ date; uptime
Sat Dec 11 11:57:33 EET 2021
11:57AM  up 310 days, 20:05, 6 users, load averages: 1.68, 1.12, 0.91

... and I know that I can temporarily order KVM service but last time I couldn't get it working because the service providers device is probably old and uses EOL Flash. I had no idea how to get the Flash working on my FreeBSD desktop...
 
You must log in or register to reply here.
Back
Top