[gentoo-user] silencing distcc with systemd

[Daniel Frey]

Hi all,

I've moved a couple of machines from openrc to systemd.

I have discovered this odd problem. On openrc, distcc was quiet during
building packages. It would obey environment variable set in /etc/env.d:

DISTCC_DIR=/var/distcc
DISTCC_ENABLE_DISCREPANCY_EMAIL=
DISTCC_FALLBACK=1
DISTCC_SAVE_TEMPS=0
DISTCC_SSH=
DISTCC_TCP_CORK=
DISTCC_VERBOSE=0

This currently shows up in the enviroment (checked with `set`.)

However, on systemd it spams messages in build logs:

distccd[290662] (dcc_check_compiler_masq) Warning:
x86_64-pc-linux-gnu-g++ on distccd's path is
/usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ and really a link to
/usr/bin/distcc
distcc[293558] (dcc_trace_version) distcc 3.4 x86_64-pc-linux-gnu; built
Mar 28 2024 05:05:38
distcc[293558] (dcc_recursion_safeguard) safeguard: 1
distcc[293558] (dcc_recursion_safeguard) safeguard level=1
distcc[293558] (main) compiler name is "x86_64-pc-linux-gnu-g++"
distcc[293558] (dcc_set_path) setting
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/17/bin
distcc[293558] exec on localhost: x86_64-pc-linux-gnu-g++ -O2 -pipe
-march=znver3 -felide-constructors -fno-strict-aliasing -pie -fPIC
-fstack-protector --param=ssp-buffer-size=4 -Wconversion
-Wno-sign-conversion -fno-omit-frame-pointer -Wall -Wenum-compare
-Wenum-conversion -Wextra -Wformat-security -Wmissing-braces
-Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
-Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla
-Wwrite-strings -std=gnu++11 -fvisibility=hidden -o
/tmp/distccd_9988a064.o -c /tmp/distccd_998ea064.ii
distcc[293558] (dcc_mkdir) ERROR: mkdir '/dev/null/.distcc' failed: Not
a directory
distcc[293558] (dcc_spawn_child) forking to execute:
x86_64-pc-linux-gnu-g++ -O2 -pipe -march=znver3 -felide-constructors
-fno-strict-aliasing -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -Wconversion -Wno-sign-conversion
-fno-omit-frame-pointer -Wall -Wenum-compare -Wenum-conversion -Wextra
-Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
-Wnon-virtual-dtor -Wvla -Wwrite-strings -std=gnu++11
-fvisibility=hidden -o /tmp/distccd_9988a064.o -c /tmp/distccd_998ea064.ii
distcc[293558] (dcc_spawn_child) child started as pid293559
distcc[293559] (dcc_increment_safeguard) setting safeguard:
_DISTCC_SAFEGUARD=2
/var/tmp/portage/dev-db/mariadb-10.6.17/work/mysql/storage/innobase/fsp/fsp0file.cc:
In member function ‘dberr_t Datafile::validate_for_recovery()’:
/var/tmp/portage/dev-db/mariadb-10.6.17/work/mysql/storage/innobase/fsp/fsp0file.cc:419:16:
warning: this statement may fall through [-Wimplicit-fallthrough=]
/var/tmp/portage/dev-db/mariadb-10.6.17/work/mysql/storage/innobase/fsp/fsp0file.cc:429:2:
note: here
distcc[293558] (dcc_collect_child) cc child 293559 terminated with status 0
distcc[293558] (dcc_collect_child) cc times: user 0.000000s, system
0.000000s, 0 minflt, 0 majflt
distcc[293558] compile (null) on localhost completed ok
distcc[293558] elapsed compilation time 1.651658s
distcc[293558] (dcc_exit) exit: code 0; self: 0.000832 user 0.000832
sys; children: 1.523681 user 0.134703 sys
distcc[293558] (dcc_mkdir) ERROR: mkdir '/dev/null/.distcc' failed: Not
a directory
distcc[293558] (dcc_cleanup_tempfiles_inner) deleted 0 temporary files


I was trying to solve this problem and it's normally set in the
environment as above.

I read systemd uses a different mechanism, but it doesn't work.

I did set /etc/systemd/system/distccd.service.d/00gentoo.conf as per
instructions I found on the wiki:
Environment="DISTCC_VERBOSE=0"
Environment="DISTCC_SAVE_TEMPS=0"
Environment="DISTCC_DIR=/var/distcc"

Reloaded using `systemctl daemon-reload` and restarted distccd -
although this is happening on the client side and it's not really the
daemon (as far as I can tell.) The output is showing up while compiling
using emerge.

I can see it's sourcing this file:
distccd.service - Distccd: A Distributed Compilation Server
Loaded: loaded (/etc/systemd/system/distccd.service; enabled;
preset: disabled)
Drop-In: /etc/systemd/system/distccd.service.d
└─00gentoo.conf
Active: active (running) since Fri 2024-03-29 22:04:12 PDT; 29min ago

Is there some other place that needs this environment set?

It clearly isn't getting the environment set somewhere in systemd as
this error is solved with the DISTCC_DIR in the file sourced above:

distcc[293558] (dcc_mkdir) ERROR: mkdir '/dev/null/.distcc' failed: Not
a directory

...and the DISTCC_VERBOSE=0 is supposed to silence build messages.

Any insight would be helpful... as this problem is easily solved in
openrc but it seem to be rather difficult with systemd.

Dan

[Alexandru N. Barloiu]

think the distcc.service file has an extra -v (--verbose). if you remove
that, it will behave as expected.

Post by Daniel Frey
Hi all,
I've moved a couple of machines from openrc to systemd.
I have discovered this odd problem. On openrc, distcc was quiet
during building packages. It would obey environment variable set in
DISTCC_DIR=/var/distcc
DISTCC_ENABLE_DISCREPANCY_EMAIL=
DISTCC_FALLBACK=1
DISTCC_SAVE_TEMPS=0
DISTCC_SSH=
DISTCC_TCP_CORK=
DISTCC_VERBOSE=0
This currently shows up in the enviroment (checked with `set`.)
* snipped the rest *

Just an update. I have figured out it isn't systemd causing this issue.
I did upgrade several machines.
1. Upgraded the system profile.
2. Converted from split-usr to merged-usr.
3. Converted to systemd.
It turns out step 2 caused the problem. I don't know why, but it does
- I tested this by converting an openrc machine that I hadn't upgraded
yet from split-usr to merged-usr and the problem presented itself (no
system on that machine yet.)
I did notice the machine I completely reinstalled from scratch (using
systemd from the start) did not show signs of this issue.
I reinstalled the other distcc host using systemd from the start,
installed and configured distcc and it all works as expected.
Now to reinstall the slower Celeron devices... come to think of it, I
initially installed them in 2011. They haven't ever been reinstalled.
Just repurposed.
Dan

[Alexandru N. Barloiu]

/etc/systemd/system/distccd.service.d/00gentoo.conf or the service file.
has to be. there cant be anything else. that's how distcc behaves when
started with -v. do a ps axw. figure out where the -v is coming from.
maybe a systemctl daemon-reload && systemctl restart distccd. cant be
anything else but a -v

Post by Alexandru N. Barloiu
think the distcc.service file has an extra -v (--verbose). if you
remove that, it will behave as expected.

I checked all the units on one of the machines still showing the
problem and an extra '-v' is not present in any of the files.
That's a good thought though. I wouldn't have even thought about that
when I was looking at the unit files initially.
Dan

[Daniel Frey]

Post by Alexandru N. Barloiu
think the distcc.service file has an extra -v (--verbose). if you remove
that, it will behave as expected.

I checked all the units on one of the machines still showing the problem
and an extra '-v' is not present in any of the files.

That's a good thought though. I wouldn't have even thought about that
when I was looking at the unit files initially.

Dan

[Alexandru N. Barloiu]

I think in the past, the service file had a -v. Somewhere near the
present, they reverted to a non -v service file. So if you keep
upgrading distcc, prolly the service file still has a -v from past
installations. If you uninstall it, and install it again, then prolly
you got the new service file which is without -v. That prolly explains
why some machines still have it, and some don't.

Post by Alexandru N. Barloiu
think the distcc.service file has an extra -v (--verbose). if you
remove that, it will behave as expected.

I checked all the units on one of the machines still showing the
problem and an extra '-v' is not present in any of the files.
That's a good thought though. I wouldn't have even thought about that
when I was looking at the unit files initially.
Dan

[Daniel Frey]

Post by Alexandru N. Barloiu
I think in the past, the service file had a -v. Somewhere near the
present, they reverted to a non -v service file. So if you keep
upgrading distcc, prolly the service file still has a -v from past
installations. If you uninstall it, and install it again, then prolly
you got the new service file which is without -v. That prolly explains
why some machines still have it, and some don't.

Post by Alexandru N. Barloiu
think the distcc.service file has an extra -v (--verbose). if you
remove that, it will behave as expected.

I checked all the units on one of the machines still showing the
problem and an extra '-v' is not present in any of the files.
That's a good thought though. I wouldn't have even thought about that
when I was looking at the unit files initially.
Dan

I did check, there's no '-v' in ps output. The systemd installations
were all new - they were converted from openrc.

276 ? SN 0:00 /usr/bin/distccd --no-detach --daemon
--port 3632 -N 15 --allow 127.0.0.1
277 ? SN 0:00 /usr/bin/distccd --no-detach --daemon
--port 3632 -N 15 --allow 127.0.0.1
278 ? SN 0:00 /usr/bin/distccd --no-detach --daemon
--port 3632 -N 15 --allow 127.0.0.1
279 ? SN 0:00 /usr/bin/distccd --no-detach --daemon
--port 3632 -N 15 --allow 127.0.0.1

I don't think it has anything to do with upgrading systemd as it was
installed fresh - I also replicated the issue after using an openrc
machine to switch to merged-usr (no systemd on it.)

Dan

[Daniel Frey]

Post by Daniel Frey
Hi all,
I've moved a couple of machines from openrc to systemd.
I have discovered this odd problem. On openrc, distcc was quiet during
DISTCC_DIR=/var/distcc
DISTCC_ENABLE_DISCREPANCY_EMAIL=
DISTCC_FALLBACK=1
DISTCC_SAVE_TEMPS=0
DISTCC_SSH=
DISTCC_TCP_CORK=
DISTCC_VERBOSE=0
This currently shows up in the enviroment (checked with `set`.)
* snipped the rest *

Just an update. I have figured out it isn't systemd causing this issue.

I did upgrade several machines.

1. Upgraded the system profile.
2. Converted from split-usr to merged-usr.
3. Converted to systemd.

It turns out step 2 caused the problem. I don't know why, but it does -
I tested this by converting an openrc machine that I hadn't upgraded yet
from split-usr to merged-usr and the problem presented itself (no system
on that machine yet.)

I did notice the machine I completely reinstalled from scratch (using
systemd from the start) did not show signs of this issue.

I reinstalled the other distcc host using systemd from the start,
installed and configured distcc and it all works as expected.

Now to reinstall the slower Celeron devices... come to think of it, I
initially installed them in 2011. They haven't ever been reinstalled.
Just repurposed.

Dan