On 5/10/19 7:33 AM, Douglas R. Reno via lfs-dev wrote:
On 5/10/19 2:21 AM, Pierre Labastie via lfs-dev wrote:
Hi,
I now build the systemd book. I may come back to SysV later, but ATM,
I want
to test the BLFS book, and the systemd revision has more thorough
coverage
than SysV.
Since i'm new to systemd, I try various commands. That's how I
realized there
was a unit (man-db.timer) for running a daily update of the man
database. So I
enabled the unit, and after one day, I received an error concerning the
associated service.
Investigating, it turns out that /usr/bin/find is hardcoded in the
unit, and
we have find in /bin...
I wonder how many units have such harcoded paths.
Looking at man-db source, /usr/bin/find is hardcoded also in
man-db.service.in. So the following sed is needed:
sed -i 's@/usr/bin/find@/bin/find@' init/systemd/man-db.service.in
Should we add it to the systemd book?
Pierre
I've got that sed in my sandbox already, but I think it would be good to
go in now.
Please add it :-)
Not many units are supposed to have hardcoded paths. I don't know if
this is related to some upstreams' initiative to push for a merged / and
/usr (where /lib and /usr/lib are symlinked, /bin and /usr/bin are
symlinked, etc). If it is, it's a very nasty way to do things. Hardcoded
paths are rarely a requirement.
More likely just an oversight because systemd itself does not support a
split /usr directory.
Would it work to just do:
sed -i 's@/usr/bin/@@' init/systemd/man-db.service.in
and let the system search the PATH?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
