Realized this is few different chroot images here at my tinderbox, details : $ qlop -u -l -H -g -f ./var/log/emerge.log tuned Tue Oct 13 05:23:33 2015 >>> sys-apps/tuned-2.5.1 tuned: Tue Oct 13 05:23:14 2015: 19 seconds tuned: 1 times $ ls -l ./%\{_* ./%{_tmpfilesdir}: total 4 -rw-r--r-- 1 root root 56 May 4 11:06 tuned.conf ./%{_unitdir}: total 4 -rw-r--r-- 1 root root 278 Jun 26 17:30 tuned.service $ tail -vf ./%\{_* ==> ./%{_tmpfilesdir} <== tail: error reading ‘./%{_tmpfilesdir}’: Is a directory tail: ./%{_tmpfilesdir}: cannot follow end of this type of file; giving up on this name ==> ./%{_unitdir} <== tail: error reading ‘./%{_unitdir}’: Is a directory tail: ./%{_unitdir}: cannot follow end of this type of file; giving up on this name tail: no files remaining
FWIW it seems to be "just" one wrong directory name under root / : drwxr-xr-x 2 root root 4096 Nov 9 06:01 /%{_tmpfilesdir}
(In reply to Toralf Förster from comment #1) > FWIW it seems to be "just" one wrong directory name under root / : > > drwxr-xr-x 2 root root 4096 Nov 9 06:01 /%{_tmpfilesdir} I just came across the referred-to directory in my /, but also have a /%{_unitdir}. The former contains a tuned.conf file and the latter a tuned.service file (systemd). Running 'equery files tuned' shows that the package claims to own both of these directory locations and their contents and therefore they are presumably required at run-time rather than having been orphaned during installation. Except that there doesn't seem to be much run-time: # systemctl status tuned Failed to dump process list, ignoring: Unit tuned.service not found. ● tuned.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) which means that the installation can't ever have worked (including for the maintainer) - at least under systemd.
Same is true for sys-apps/tuned-2.7.1
Created attachment 450564 [details, diff] Patch tuned-2.7.1-r1 to tuned-2.7.1-r2 On a CentOS server rpm returns these values: $ rpm --eval '%{_unitdir}' /usr/lib/systemd/system $ rpm --eval '%{_tmpfilesdir}' /usr/lib/tmpfiles.d $ But simply returns the literal values on a gentoo server (and return code 0): $ rpm --eval '%{_unitdir}' %{_unitdir} $ echo $? 0 $ rpm --eval '%{_tmpfilesdir}' %{_tmpfilesdir} $ echo $? 0 $
Created attachment 450566 [details, diff] Patch to Makefile (rpm lookup fix)
(In reply to Adrian.Bassett from comment #2) > (In reply to Toralf Förster from comment #1) > > FWIW it seems to be "just" one wrong directory name under root / : > > > > drwxr-xr-x 2 root root 4096 Nov 9 06:01 /%{_tmpfilesdir} > > I just came across the referred-to directory in my /, but also have a > /%{_unitdir}. The former contains a tuned.conf file and the latter a > tuned.service file (systemd). Running 'equery files tuned' shows that the > package claims to own both of these directory locations and their contents > and therefore they are presumably required at run-time rather than having > been orphaned during installation. > > Except that there doesn't seem to be much run-time: > > # systemctl status tuned > Failed to dump process list, ignoring: Unit tuned.service not found. > ● tuned.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead) > > which means that the installation can't ever have worked (including for the > maintainer) - at least under systemd. I'm not able to re-produce this, did you ever try to enable tuned.service first? (run "systemctl enable tuned.service") # systemctl status tuned.service ● tuned.service - Dynamic System Tuning Daemon Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; vendor preset: disabled) Active: active (running) since 二 2016-11-01 17:55:36 CST; 5h 45min ago Main PID: 6116 (tuned) CGroup: /system.slice/tuned.service └─6116 /usr/bin/python2.7 -Es /usr/sbin/tuned -l -P
FWIW at the tinderbox I didn't code a special handling for testing of a systemd profile. So the tinderbox is rather similar to the case where somebody unpacks a stage3 image, chroots into it to setup it and whilst there emerges all packages he do need w/o really booting into nor running some *ctl scripts.
Created attachment 452090 [details, diff] rework the rpm look patch (In reply to Paul Healy from comment #5) > Created attachment 450566 [details, diff] [details, diff] > Patch to Makefile (rpm lookup fix) hello, just tested and sounds I have no problem even without this patch.. $ qlist -e tuned |grep service /usr/lib/systemd/system/tuned.service $ qlist -e tuned |grep tmp /usr/lib/tmpfiles.d/tuned.conf but on the other hand, obviously I see the value of this patch, so I just re-work it to make it upstream acceptable, thanks
hi Toralf Förster, could you give a shoot at sys-apps/tuned-2.7.1-r2, and see if you still have problem?
(In reply to Yixun Lan from comment #9) solved - thx
Hi, I am Tuned upstream. I don't understand why it doesn't work for you without patching. There is e.g. the folllowing in the original (unpatched) Tuned Makefile: UNITDIR = $(shell rpm --eval '%{_unitdir}' 2>/dev/null || echo /usr/lib/systemd/system) So if there is no RPM installed the rpm command silently fails with 'rpm: command not found...' error and 'echo /usr/lib/systemd/system' is run which should result in UNITDIR set to the /usr/lib/systemd/system. From the manual page of the 'which' command: 'Which takes one or more arguments. For each of its arguments it prints to stdout the full path of the executables that would have been exe‐ cuted when this argument had been entered at the shell prompt. It does this by searching for an executable or script in the directories listed in the environment variable PATH using the same algorithm as bash(1).' And: 'RETURN VALUE Which returns the number of failed arguments, or -1 when no `program‐ name´ was given.' So it should behave the same way as the bash. As you end with unexpanded macros (e.g. '%{_unitdir}') it means that there is executable rpm command known to the shell Makefile uses but not to the 'which' command. Also it seems that the rpm command known to the shell doesn't work correctly, because it cannot expand the macro. This is strange and I think that the proposed fix is probably only hiding the real problem. Could anybody provide reproducer for this problem? I would debug it on my gentoo box.
(In reply to Toralf Förster from comment #10) damn - appropriate check was just deactivated to not ring the bell every day and I forget about that. So-r2 did no solve it : tinderbox@mr-fox ~ $ ls amd64-*/%\{_* amd64-13.0-libressl-unstable_20161026-090714/%{_tmpfilesdir}: tuned.conf amd64-13.0-libressl-unstable_20161026-090714/%{_unitdir}: tuned.service tinderbox@mr-fox ~ $ ls -ld amd64-*/%\{_* drwxr-xr-x 1 root root 20 Nov 1 21:10 amd64-13.0-libressl-unstable_20161026-090714/%{_tmpfilesdir} drwxr-xr-x 1 root root 26 Nov 1 21:10 amd64-13.0-libressl-unstable_20161026-090714/%{_unitdir} tinderbox@mr-fox ~ $ sudo chroot amd64-13.0-libressl-unstable_20161026-090714 mr-fox / # eix -I tuned [I] sys-apps/tuned Available versions: (~)2.7.0 (~)2.7.1 (~)2.7.1-r1 (~)2.7.1-r2 {PYTHON_TARGETS="python2_7"} Installed versions: 2.7.1-r2(09:09:59 PM 11/01/2016)(PYTHON_TARGETS="python2_7") Homepage: https://fedorahosted.org/tuned/ Description: Daemon for monitoring and adaptive tuning of system devices mr-fox / # exit exit tinderbox@mr-fox ~ $
Created attachment 452180 [details, diff] Proposed fix Isn't possible that you have rpm package but not systemd macros? The proposed patch should resolve such situations.
(In reply to Yarda from comment #13) this patch makes sense IMO (according to my #comment 7)
(In reply to Toralf Förster from comment #14) > (In reply to Yarda from comment #13) > this patch makes sense IMO (according to my #comment 7) Thanks for info. Could anybody confirm that it resolves this problem? I would push it upstream.
(In reply to Yarda from comment #15) > (In reply to Toralf Förster from comment #14) > > (In reply to Yarda from comment #13) > > this patch makes sense IMO (according to my #comment 7) > > Thanks for info. > > Could anybody confirm that it resolves this problem? I would push it > upstream. Hi Yarda, I can confirm that this patch fixes the problem for me at least. And in my case, I have rpm installed so that I can build CentOS lxc containers. Thanks. Paul
(In reply to Paul Healy from comment #16) > (In reply to Yarda from comment #15) > > (In reply to Toralf Förster from comment #14) > > > (In reply to Yarda from comment #13) > > > this patch makes sense IMO (according to my #comment 7) > > > > Thanks for info. > > > > Could anybody confirm that it resolves this problem? I would push it > > upstream. > > Hi Yarda, > > I can confirm that this patch fixes the problem for me at least. > > And in my case, I have rpm installed so that I can build CentOS lxc > containers. > > Thanks. > > Paul Thanks for info, I pushed the patch upstream: https://git.fedorahosted.org/cgit/tuned.git/commit/?id=7e3a4fd79150ea9802733680dcaa4da5f2d41700
thanks all!! since this is only a build time issue, so I just pushed without revision bump (so users don't have to build/install again if they already installed this package) commit a79cf3e4000ed0a3e7229ea4257fced00c8058db Author: Yixun Lan <dlan@gentoo.org> Date: Fri Nov 4 10:54:49 2016 +0800 sys-apps/tuned: fix wrong systemd path if rpm installed Gentoo-Bug: 563396 Package-Manager: portage-2.3.2 :000000 100644 00000000.. 408ef2b... A sys-apps/tuned/files/tuned-2.7.1-makefile-rpm.patch :100644 000000 54e89a1... 00000000.. D sys-apps/tuned/files/tuned-2.7.1-makefile.patch :100644 100644 6c58913... eed443e... M sys-apps/tuned/tuned-2.7.1-r2.ebuild
