Bug 229509 – sys-devel/distcc service will be stopped, but never restarted (by portage/emerge)

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Steffen Bergner 2008-06-26 08:40:07 UTC]

automatically stopped service after rebuild, but never restarted automatically again

Reproducible: Always

Steps to Reproduce:
1. /etc/init.d/distccd start
2. emerge -ev world
3. /etc/init.d/distccd status

Actual Results:  
distccd is stopped by portage

Expected Results:  
new built version of distccd is supposed to be restarted/run

[Comment 1 Carsten Lohrke (RETIRED) 2008-06-26 12:34:04 UTC]

There's a fat post install warning, that you have to run etc-update before starting distcc again.

[Comment 2 Steffen Bergner 2008-06-26 12:42:17 UTC]

Is etc-update necessary for "emerge -ev world", specially distcc in mind?

if update/newer/first install of distcc -> etc-update / manual restart
else (if emerge -ev) automatic restart?

[Comment 3 Carsten Lohrke (RETIRED) 2008-06-26 15:16:28 UTC]

(In reply to comment #2)
> Is etc-update necessary for "emerge -ev world", specially distcc in mind?

Why don't you read the ebuild?! You have to adjust the config file to match your environment and therefore neither the (old) default nor a possibly changed default config file will match it. You have to interact with the system.

What would be possible is to keep a history of changes and match against your past decisions, so a restart could be based on the information, when neither the init scrit nor the default config did change after your last manual change. But this would need a whole infrastructure and is beyond some simple code change within a single package, would imply more complexity and a new class of errors.

You are the admin of your systems, there's nothing to avoid this in the end.

[Comment 4 Steffen Bergner 2008-06-27 06:52:14 UTC]

Ok. Then let's face it as a "feature request" for a future future of Gentoo.

From time to time I let the whole Gentoo installs (ESX servers and some old PIIIs) recompile from scratch. (*)

So my fast esx-servers reemerge from ground and running distcc-daemon. My old PIIIs are doing reemerging too and would be faster with a running distcc-daemon on ESXs (fast multicore servers), but later the distccd is stopped on ESX and PIIIs have to compile all alone... and I am not there to restart distccd.

The use of binpkgs for the PIIIs is no option, different C-flags, but I am using binpkgs for the ESX-servers. But even the binpkg-emerged ESX stops the distccd and never restarts self... but ehm... ok I will use the binpkg ESX server for distccd, because the reemerge of this machine is fastest and I am mostly at place when all the pkgs got reemerged.

Just some thoughts... but helped. Thanks ;)


*) (even with FEATURES="test").

I have to do a lot of /etc/portage/env/package* individual settings (some packages always need "-test", because of test-package misconfiguration (not of compile failures! - binutils, hal-info, deja-gnu, pygobjects... other story).