ksm-control-daemon is being helt back

mo_

Active Member
Oct 27, 2011
401
6
38
Germany
I'm looking at this

Code:
The following packages have been kept back:
  ksm-control-daemon

after the upgrade to debian8 and dpkg reports as

Code:
ii  ksm-control-daemon             1.1-1                          all          The KSM tuning daemon

Question is, is there a poettering-free version of this package so I can upgrade?
 
Thanks. I tried that but it did only tell me the same thing. However I have since figured out theres a weird systemd dependency lingering now (WHY?), which I managed to resolve. Am now digging into PVE/Services.pm and Tools.pm to replace calls to the nonexistant "systemctl" binary

Status: was making progress, am now stuck at

API2/Services.pm L42..:
Code:
my $parser = sub {
        my $line = shift;
        if ($line =~ m/^([^=\s]+)=(.*)$/) {
            $res->{$1} = $2;
        }
    };

which seems to not be built to understand "pvedaemon is running" anymore. Could anybody with access to a poettering'd system tell me how the output of "systemctl something show" looks like?



Also, been kinda busy lately, did I miss the switch to systemd? Any reading on that? Primarily forks/workarounds? Cant be the first guy to have stumbled into this
 
Last edited:
jessie (currently) defaults to the (optional) systemd. Much like SLES12 defaults to btrfs but also supports stable filesystems

Does that mean that proxmox has dropped support for sysvinit entirely? That doesn't seem right. Even so, seems like a tiny change to the Services.pm could easily alleviate that
 
Last edited:
is this up for constructive debate on pve-devel or something? I understand systemd discussions tend to get heated very quickly but I dont think this would be about systemd exactly, more about freedom of choice (minor aspect) and supporting stable, established architectures (bigger aspect).

From what I can tell the required changes would be a total of 15ish lines of perl (most of which can even be replaced with sed), so this seems very managable at first glance (which can be deceptive, I know). Unfortunately I'm an architect, not a developer so I don't think I should try to maintain an external package to do these perl modifications but maybe somebody can find it in their heart to do so? To me this doesn't seem that much of extra work to be worth the downsides of not offering the choice. This would really probably even only be needed this until uselessd is finished.
 
Proxmox VE 4.0 uses systemd, the decision was made already more than a year ago. You can discuss this but no, the project will/can not move away from systemd.
 
From what I can tell the required changes would be a total of 15ish lines of perl

We spent really much time into correct startup/shutdown behavior. This is non-trivial, complex, and more that 15 lines of perl.
 
We spent really much time into correct startup/shutdown behavior. This is non-trivial, complex, and more that 15 lines of perl.

That's why I wrote "at first glance", thanks for the correction. The amount of work that went into this was not transparent to me, no offense intended!

Also thanks for the answers to you both, even though I find this situation to be extremely unfortunate. As it turns out Ceph did the same thing (Ceph Infernalis and newer only support systemd and upstart) even though when Sage asked on ceph-users how people felt about dropping support for debian7 long before its support would run out (there will be LTS support for it after all, which is extremely fortunate), the general consensus was that he shouldn't do it. But then again they're somewhat owned by Redhat now and they have been pushing hard for systemd...

Anyhow, seems to me like I just have to bite the bullet and use systemd on Proxmox and Ceph servers, meaning diagnostic options for those systems will be very limited. But at least I/we can continue using debian7 (got LTS support) and RHEL6 (or SLES 11.4 respectively) for quite a while longer... hopefully when the support for those runs out, uselessd will be done (fingers crossed).
 
Last edited:
Anyhow, seems to me like I just have to bite the bullet and use systemd ...

The move to systemd is painful for everyone... But the hope is that this is the last time we have to change the init system ;-)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!