Project

General

Profile

Actions

Bug #16789

closed

rudder-agent v5.0.16 for debian 9 tries to use init.d instead of systemd

Added by Victor Héry over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
N/A
Assignee:
-
Category:
Packaging
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
To do
Fix check:
To do
Regression:

Description

Hello

While trying to update my agent to the last version before 6.0, I get a bug in the package on debian 9.

I am trying to update to the 5.0.16 through official package, and the debian 9 package tries to use init.d script instead of systemd unit:

E: Sub-process /usr/bin/dpkg returned an error code (1)
Paramétrage de rudder-agent (5.0.16-debian9) ...
update-rc.d: error: initscript does not exist: /etc/init.d/rudder-agent

It seems it use update-rc.d to enable the agent at start instead of systemctl enable

Before this version, the agent worked perfectly with a systemd unit, which is still seen by the system:

# systemctl status rudder-
rudder-agent.service       rudder-cf-execd.service    rudder-cf-serverd.service 

But not present anymore:

# systemctl status rudder-agent.service 
Unit rudder-agent.service could not be found.

My best guess is something went wrong in the packaging, messing up with some debian 8 files, which still use init.d

Could it be possible to have a fix for this, in order to be able to upgrade properly to the last 5.0 before upgrading to 6, or upgrading to 6 should be possible even with the package broken?

Thanhs :)

Regards

Actions #1

Updated by Alexis Mousset over 4 years ago

Could not reproduce for now:

  • From which version are you upgrading?
  • Is it i383 or amd64?
Actions #2

Updated by Victor Héry over 4 years ago

Hello,

From my history, it's an upgrade from the 5.0.15 :

[UPGRADE] rudder-agent:amd64 5.0.15-debian9 -> 5.0.16-debian9
Sat, Feb 22 2020 12:52:26 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 0 packages, and remove 0 packages.
========================================
[UNCONFIGURED] rudder-agent:amd64 5.0.16-debian9
========================================

The system is amd64.

In december I have upgraded from v5.0.14 without problem:

Fri, Dec 13 2019 20:52:43 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 1 packages, and remove 0 packages.
========================================
[UPGRADE] rudder-agent:amd64 5.0.14-debian9 -> 5.0.15-debian9
========================================

Hope it helps! 🙏

Actions #3

Updated by Alexis Mousset over 4 years ago

Thanks, still not reproduced. Was this node in Rudder 4 before?

It could be a problem with the logic for migration to systemd unit.

What does these give:

ls /var/rudder/tmp/migration-*
dpkg -L rudder-agent | grep systemd

The systemd units should be there anyway so it's really strange.

Actions #4

Updated by Victor Héry over 4 years ago

This node was in debian 8 some time ago, but long before the upgrade to 5.0.14.

Altought it has alway used rudder 5, no rudder 4 in this infrastructure.

I have other nodes in this case (upgraded for debian 8, and even debian 7 before), but without the problem, strange.

Here are the result of commands:

# ls /var/rudder/tmp/migration-*
/var/rudder/tmp/migration-rudder-service-enabled  /var/rudder/tmp/migration-rudder-service-enabled-server  /var/rudder/tmp/migration-rudder-service-rename
# dpkg -L rudder-agent | grep systemd
/lib/systemd
/lib/systemd/system
/lib/systemd/system/rudder-agent.service
/lib/systemd/system/rudder-cf-execd.service
/lib/systemd/system/rudder-cf-serverd.service
Actions #5

Updated by Alexis Mousset over 4 years ago

Victor Héry wrote:

This node was in debian 8 some time ago, but long before the upgrade to 5.0.14.

Altought it has alway used rudder 5, no rudder 4 in this infrastructure.

This is strange.

I have other nodes in this case (upgraded for debian 8, and even debian 7 before), but without the problem, strange.

Here are the result of commands:

[...]

To fix the problem you can probably remove the /var/rudder/tmp/migration-* files which should have been removed at the end of the migration, but have not been for some reason.

Actions #6

Updated by Victor Héry over 4 years ago

Indeed, removing all files in /var/rudder/tmp/migration-* does the trick 🎉

I need to manually restart daemon from systemctl: systemctl daemon-reload (but probably because I have tried to tally remove the rudder-agent) and after that, it updates and works properly.

Thank you a lot!

You may close :-)
(I am not able to set the statut to "Closed" myself)

Actions #7

Updated by Alexis Mousset over 4 years ago

  • Status changed from New to Resolved

Good, thanks for your feedback, closing.

Actions

Also available in: Atom PDF