Is Arch meant for achieving long uptimes?

jetten · 2015-03-01 00:28:30

I created my account earlier today to ask a stupid question about USB devices not charging when TLP was autosuspending them, but luckily I resolved my problem by myself seconds before posting that question...

Anyhow I've been running Arch for almost a year, and with a server running now for about 6 months. Usually I get problems when I try to get Virtualbox running on my server, since it seems "modprobe vboxdrv" is never working, probably because I have updated the kernel and not rebooted since, and it usually works after a reboot. I tried switching to the LTS kernel, but it appears I've updated from 3.14.32 to 3.14.33 without rebooting the machine yet. Today I installed virtualbox-guest-modules-lts, reloaded the kernel modules (modprobe vboxdrv), but still Virtualbox is refusing to start with "Kernel driver not installed". I suppose the kernel modules are refusing to load because of the kernel update without having rebooted the machine yet.

I want to ask if Arch is meant for servers where long uptimes are desirable? Having to reboot the machine every other week after a new lts-kernel update is available is a little too often if you ask me. Is it then just me that is doing something wrong, or am I really supposed to have to reboot after every kernel update? Would it work better to simply not install any kernel updates (but then I suppose I would have to blacklist other packages as well)?

Alad · 2015-03-01 00:43:17

https://wiki.archlinux.org/index.php/Us … _server.3F

lucke · 2015-03-01 00:44:56

You can put linux or linux-lts and modules depending on them in IgnorePkg in pacman.conf and update them manually whenever you want with "pacman -S linux other_packages".

It seems Debian wheezy's kernel was updated 25 times since wheezy's release (May 2013).

jasonwryan · 2015-03-01 00:46:36

People use Arch for servers, but I think it isn't worth the candle: if you don't want to maintain it, use Debian.

If you are not installing updates and have a list of packages blacklisted, you should ask why you are running a rolling release at all...

Also: https://bbs.archlinux.org/viewtopic.php?id=162434

https://bbs.archlinux.org/viewtopic.php?id=62093

https://bbs.archlinux.org/viewtopic.php?id=50021

https://bbs.archlinux.org/viewtopic.php?id=108319

etc...

jetten · 2015-03-01 01:10:28

lucke wrote:

You can put linux or linux-lts and modules depending on them in IgnorePkg in pacman.conf and update them manually whenever you want with "pacman -S linux other_packages".
It seems Debian wheezy's kernel was updated 25 times since wheezy's release (May 2013).

Thanks! I think blacklisting linux and virtualbox-host-modules here will probably be the solution I am looking for.

jasonwryan wrote:

People use Arch for servers, but I think it isn't worth the candle: if you don't want to maintain it, use Debian.
If you are not installing updates and have a list of packages blacklisted, you should ask why you are running a rolling release at all...
Also: https://bbs.archlinux.org/viewtopic.php?id=162434
https://bbs.archlinux.org/viewtopic.php?id=62093
https://bbs.archlinux.org/viewtopic.php?id=50021
https://bbs.archlinux.org/viewtopic.php?id=108319
etc...

Well, to be honest I don't see any difference with using Debian which is not updated much, or using Arch and simply not updating (the kernel) much. Furthermore, I know updating to a new release of Debian/Ubuntu is not always fun either, something I hope to be spared from when running Arch. Thank you very much for the links though!

Head_on_a_Stick · 2015-03-01 01:55:22

jetten wrote:

Well, to be honest I don't see any difference with using Debian which is not updated much, or using Arch and simply not updating (the kernel) much.

Arch supplies (mostly) unpatched untested upstream software; Debian (Stable) supplies patched extensively tested and debugged software.

You would be much better off with Debian Stable in the situation you describe (IMO).

EscapedNull · 2015-03-01 02:29:06

jetten wrote:

... because I have updated the kernel and not rebooted since, and it usually works after a reboot. I tried switching to the LTS kernel, but it appears I've updated from 3.14.32 to 3.14.33 without rebooting the machine yet.

Pacman removes all old modules from the filesystem as soon as it upgrades the kernel. See module handling.

jetten wrote:

I want to ask if Arch is meant for servers where long uptimes are desirable? Having to reboot the machine every other week after a new lts-kernel update is available is a little too often if you ask me. Is it then just me that is doing something wrong, or am I really supposed to have to reboot after every kernel update? Would it work better to simply not install any kernel updates (but then I suppose I would have to blacklist other packages as well)?

I don't think there's a right answer. I for one use the stock kernel on my servers; I usually upgrade and reboot whenever a minor version update of the kernel comes out (every two to three months, usually), or if a package is updated that I'm particularly interested in trying out. This generally gives me uptimes of two to three months, but sometimes longer if I'm lazy. Most of the time, the upgrade goes smoothly and is done in a few minutes, but occasionally something will break and I'll spend hours figuring out what happened. I also run a few systemd-nspawn containers which tend to get upgraded at various frequencies, depending on the services inside and regardless of the host system.

As far as I am aware, there's just no way to update a kernel without rebooting, so you're stuck with the one you're running until you reboot, regardless of the distro. I do find it surprising that LTS kernel updates come out more often than standard releases, however (1-2 weeks vs 2-3 months). That being said, Head_on_a_Stick makes a good point about using Debian for long-running, stable packages instead of Arch, if you don't want to reboot often. The only problem there is, although your kernel will be more stable, you'll be stuck using Debian's year-old packages for many of your applications (containers are a way around this, but beyond the scope of this post).

WFV · 2015-03-02 06:08:41

jasonwryan wrote:

If you are not installing updates and have a list of packages blacklisted, you should ask why you are running a rolling release at all...
...

My son convinced me to switch to Arch last time Mint crashed totally on a major update (wasn't the first time either). Then an -Syu crashed after a few months, re-installed from bottom up. Now I find that certain apps fail to perform or even launch after -Syu, so i roll them back and blacklist them. I was (and still am) no where near the level of competency needed to operate Arch Linux but its been running a month shy of 2yrs with two successful -Syu's on my own without son's help, he's not in a place where he can assist me now, i lost my Arch live tech support :.(
So I have a dumb question: is the intent of Arch rolling aimed at programmers and developers primarily?

Apps that I have problems with after -Syu are: audacious, audacious-plugins, audacity, brasero, catfish, gnome-mahjongg, gparted, k3b, kid3, pavucontrol, and soundconverter. I' had to roll back vbox with the November 2014 -Syu because I couldn't get virtual machines to reload, it did say they would have to be reloaded, I don't fault Arch or VBox or Linux for this, I'm sure I am not savvy enough to figure out how to correct the problems nor have i found solutions on the web yet. So I run a vbox of Arch (on my Arch host) for testing -Syu's on most apps when I can, also so I can remember how to re-install my host OS if need to down the road. Thanks.

-Bill

nullified · 2015-03-02 06:18:18

WFV wrote:

is the intent of Arch rolling aimed at programmers and developers primarily

That does not seem like an explicit aim of Arch and it certainly isn't required. But it makes sense that developers and other hacker/maker types would be drawn to Arch--a willingness to learn about one's system is a kind of expectation.

bleach · 2015-03-02 06:33:55

a lot of uptade do not need a reboot(though might need some config or other mitigating action). the kernal is another issue intirely and would need a reboot for the boot loader to load it. there are a lot of suggestins here and I would agree; lts is probably your best bet for it is not updated in a system like arch which is a rolling release you will see many updates including kernal as soon as it is stable enough for this distro.

chaonaut · 2015-03-02 14:14:59

the question is rather about kernel and systemd release cycles, than any specific distro using them
btw, ubuntu releases kernel updates for any branches including LTS quite often.

fsckd · 2015-03-02 14:30:43

Kernel updates bring security fixes. OP may want to consider a system for patching a running kernel. I haven't used any, so I don't know how well they work in Arch or if they work for the scenario described by OP.

nullified · 2015-03-03 23:16:38

fsckd wrote:

Kernel updates bring security fixes. OP may want to consider a system for patching a running kernel.

That's on the docket for 4.0. With the option to live patch the kernel, and thus to mitigate security concerns without going down, I would be tempted myself to use Arch for a server.

ANOKNUSA · 2015-03-04 05:13:15

jetten wrote:

Having to reboot the machine every other week after a new lts-kernel update is available is a little too often if you ask me. ... to be honest I don't see any difference with using Debian which is not updated much, or using Arch and simply not updating (the kernel) much.

The challenge is not in properly maintaining and updating an Arch server. It's an Arch installation like any other. No, the challenge is in remembering to properly maintain and update and maintain an Arch server. And if you spend nearly 200 days in a row saying "I don't need to do this," you're gonna be primed to just stop thinking about it, until eventually a problem crops up. Even if you're only talking about a kernel upgrade, letting something like that go for a long time makes it that much easier to overlook something like a change in configuration file syntax or a *.pacnew file or a subtle change in filesystem hierarchy or whatever. Distros like Debian, Slackware and CentOS tend to be better at handling bi-monthly full system updates than a bleeding-edge rolling release ever could be.

So, two simple questions: "How long did you spend trying to figure out what was wrong with VirtualBox?" and "How long does it take to reboot your system?"

chaonaut · 2015-03-09 12:56:55

good news about kernel
No reboot patching comes to Linux 4.0

madeye · 2015-03-11 15:50:22

I run Arch on my servers, and update them regularly. I don't really get the hype about having a long uptime.
I think it is more necessary to keep the system updated as to not be vulnerable to exploits. They tend to pop up now and again.
And let's face it. It doesn't take that long to restart a system...

Of course it's a good idea to check the archlinux homepage and the forums before you update, if you are afraid something will break. Basically that's what I do.

poiuyt23 · 2015-03-11 16:17:44

madeye wrote:

I run Arch on my servers, and update them regularly. I don't really get the hype about having a long uptime.

I was the sysadmin for a small chain of banks back in the day. There were a couple machines that if I rebooted them credit authorizations would not flow.
Big Deal?

madeye · 2015-03-11 17:54:11

In that case I can understand the reluctancy to reboot a machine. But then I would also say something is wrong with the software and that such a problem should be solved.
What would happen if the machines had a security flaw that made it possible for someone to steal creditcard information?

The uptime I was referring to was more of the kind of: "Man I'm good. My machine has an uptime of 20 years, how is yours?"

anatolik · 2015-03-11 18:30:42

poiuyt23 wrote:

madeye wrote:
I run Arch on my servers, and update them regularly. I don't really get the hype about having a long uptime.
I was the sysadmin for a small chain of banks back in the day. There were a couple machines that if I rebooted them credit authorizations would not flow.
Big Deal?

The better solution in this case would be implementing some kind of fault-tolerance solution. i.e. keep a pool of servers and add a balancer that tracks what machines are alive. Requests should be send only to such alive servers. In this case software (both business applications and kernel) can be updated gradually one by one without any user-visible interruption.

Inxsible · 2015-03-11 20:50:15

For home and desktop users, I think having a long uptime is nothing but a pissing contest. I have no qualms about switching off my machine when not in use. Saves me a ton of money in electricity etc. Less wear and tear on the components too as they are used only when required.

My server on the other hand ....

jetten · 2015-03-11 22:12:12

madeye wrote:

I run Arch on my servers, and update them regularly. I don't really get the hype about having a long uptime.
I think it is more necessary to keep the system updated as to not be vulnerable to exploits. They tend to pop up now and again.
And let's face it. It doesn't take that long to restart a system...
Of course it's a good idea to check the archlinux homepage and the forums before you update, if you are afraid something will break. Basically that's what I do.

Well I used to not care about uptime either, when I was running only a webserver. Now when I also run an IRC-bouncer and a Teamspeak-server, I care more about my uptime. Partly because I am somewhat reluctant to spam several "User joins/leaves channel", in an IRC-channel that otherwise might remain dead silent for months. Partly because I have to find a time to reboot when there's not much activity on my Teamspeak-server, as I can not afford the reputation hit I would take if I'd reboot in the middle of peoples conversation or when they are in the middle of a multiplayer game.

I want to thank you all for the hints I got from this thread. I now blacklisted the kernel and the packages that depend on it (virtualbox-host-modules) in pacman.conf. I also used the Arch Rollback Machine to downgrade my kernel and virtualbox-host-modules to the version that was installed at the time of my last reboot, and that way I got Virtualbox working again without having to reboot at all.

I know some people here says I should switch to Debian, but I still do not see what advantage I would get from that. If I do not want to reboot a Debian-machine, (I suppose) I'd not be able to update the kernel on that machine either.

poiuyt23 · 2015-03-12 12:30:59

anatolik wrote:

The better solution in this case would be implementing some kind of fault-tolerance solution. i.e. keep a pool of servers and add a balancer that tracks what machines are alive. Requests should be send only to such alive servers. In this case software (both business applications and kernel) can be updated gradually one by one without any user-visible interruption.

Agreed. The solution was mine to support, not mine to design. That said when the new solution went in place it cost about 1/5th of the yearly profit to implement. No doubt a difficult sell to add cost for redundancy.

Buddlespit · 2015-03-13 02:01:49

jetten wrote:

Well I used to not care about uptime either, when I was running only a webserver. Now when I also run an IRC-bouncer and a Teamspeak-server, I care more about my uptime. Partly because I am somewhat reluctant to spam several "User joins/leaves channel", in an IRC-channel that otherwise might remain dead silent for months. Partly because I have to find a time to reboot when there's not much activity on my Teamspeak-server, as I can not afford the reputation hit I would take if I'd reboot in the middle of peoples conversation or when they are in the middle of a multiplayer game.

I want to thank you all for the hints I got from this thread. I now blacklisted the kernel and the packages that depend on it (virtualbox-host-modules) in pacman.conf. I also used the Arch Rollback Machine to downgrade my kernel and virtualbox-host-modules to the version that was installed at the time of my last reboot, and that way I got Virtualbox working again without having to reboot at all.
I know some people here says I should switch to Debian, but I still do not see what advantage I would get from that. If I do not want to reboot a Debian-machine, (I suppose) I'd not be able to update the kernel on that machine either.

I also run Teamspeak virtual servers (three virtual servers on the TS3 server). On Sunday mornings at 6am, I update and reboot my Arch based server. I'll open my TS3 web interface and blast a server-wide announcement that 'the server will be rebooting in 5 minutes. Don't panic, you'll be automatically reconnected'. That's only if I need to reboot. But also, I'm only supplying TS3 to my clans/guilds in games I play. But yeah, I won't reboot the server during peak play times. Heck, every game I've run across has some kind of maintenance schedule where there's some kind of downtime/reboot. And if there's some kind of emergency reboot, they spam it in whatever chat is available with a timer. I'm sure the gamers you have on your server would understand a 2-minute downtime if you give them time to prepare.

Sometimes, like tomorrow morning, I'll take the server down for a few hours to do hardware upgrades. I posted that in forums and changed all of the servers MOTD's to reflect that ('Server will be down until noon, eastern time').

Meskarune · 2015-04-16 20:29:58

I personally think security and upgrades are more important than up time, and if you have critical things running that absolutely can't go down, then build them to be redundant and fault tolerant.

If you want to avoid rebooting an Arch server, you can use the LTS kernel and of course blacklist the kernel and headers and then update when it is a good time for you and your users. I really don't think using Debian has any advantage over Arch in regards to that. I'd rather have more updated packages and an Arch system than a Debian one.

WFV · 2015-06-28 22:47:17

nullified wrote:

WFV wrote:
is the intent of Arch rolling aimed at programmers and developers primarily
That does not seem like an explicit aim of Arch and it certainly isn't required. But it makes sense that developers and other hacker/maker types would be drawn to Arch--a willingness to learn about one's system is a kind of expectation.

Thank you for reply. Yes it makes sense and the expectation - I'm still learning real basic Linux stuff that many Archers have mastered before switching to Arch.

Arch Linux

#1 2015-03-01 00:28:30

Is Arch meant for achieving long uptimes?

#2 2015-03-01 00:43:17

Re: Is Arch meant for achieving long uptimes?

#3 2015-03-01 00:44:56

Re: Is Arch meant for achieving long uptimes?

#4 2015-03-01 00:46:36

Re: Is Arch meant for achieving long uptimes?

#5 2015-03-01 01:10:28

Re: Is Arch meant for achieving long uptimes?

#6 2015-03-01 01:55:22

Re: Is Arch meant for achieving long uptimes?

#7 2015-03-01 02:29:06

Re: Is Arch meant for achieving long uptimes?

#8 2015-03-02 06:08:41

Re: Is Arch meant for achieving long uptimes?

#9 2015-03-02 06:18:18

Re: Is Arch meant for achieving long uptimes?

#10 2015-03-02 06:33:55

Re: Is Arch meant for achieving long uptimes?

#11 2015-03-02 14:14:59

Re: Is Arch meant for achieving long uptimes?

#12 2015-03-02 14:30:43

Re: Is Arch meant for achieving long uptimes?

#13 2015-03-03 23:16:38

Re: Is Arch meant for achieving long uptimes?

#14 2015-03-04 05:13:15

Re: Is Arch meant for achieving long uptimes?

#15 2015-03-09 12:56:55

Re: Is Arch meant for achieving long uptimes?

#16 2015-03-11 15:50:22

Re: Is Arch meant for achieving long uptimes?

#17 2015-03-11 16:17:44

Re: Is Arch meant for achieving long uptimes?

#18 2015-03-11 17:54:11

Re: Is Arch meant for achieving long uptimes?

#19 2015-03-11 18:30:42

Re: Is Arch meant for achieving long uptimes?

#20 2015-03-11 20:50:15

Re: Is Arch meant for achieving long uptimes?

#21 2015-03-11 22:12:12

Re: Is Arch meant for achieving long uptimes?

#22 2015-03-12 12:30:59

Re: Is Arch meant for achieving long uptimes?

#23 2015-03-13 02:01:49

Re: Is Arch meant for achieving long uptimes?

#24 2015-04-16 20:29:58

Re: Is Arch meant for achieving long uptimes?

#25 2015-06-28 22:47:17

Re: Is Arch meant for achieving long uptimes?

Board footer