On 02/02/2018 04:31 AM, Tom Horsley wrote: rpm is now running some tasks asynchronously using temporary systemd units. I don't know which tasks are being done this way, but I expect at least the mandb update is. If you were quick enough, you should have been able to get more info by running "systemctl status run-r1880116b569f49288e6d0da0c5832367.service".

On 02/04/18 09:57, Todd Zullinger wrote: Snip Snip Thanks for doing the research. But please be aware that you're subverting the plot by a secret society to produce copious indecipherable output so users will switch over to GUIs and have things hidden from view.  :-) :-)     -- A motto of mine is: When in doubt, try it out

Tom Horsley wrote: Haha. :) They'll pry my TUI from my cold, carpal-tunnel-syndrome'd hands. I still remember many years ago, before I heard of linux, someone's reason for preferring computerized text files to a book with the same data: "I can't grep a dead tree." So as long as we can grep the code, the secrets can't be too well hidden. ;) -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ How much does it cost to entice a dope-smoking UNIX system guru to Dayton? -- Brian Boyle, UNIX/WORLD's First Annual Salary Survey

Samuel Sieb wrote: IMO, it's not useful because it tells the user nothing about what script is actually running. What useful information is included in: Running as unit: run-re2635381e8fe44a6aad4926eddab6961.service It says that something is running, but no detail about what it is. If more scriptlets add similar calls to systemd-run, then we'll just have more of those lines, none of which allow a user to do anything without digging into the logs to see what service was actually run. And since the information is already in the logs, sending the least useful part of it to stdout during the rpm transaction is not of any real value. This is similar to enabling or starting a service in %post. The output from systemctl start (or /sbin/service, from way back) isn't sent to stdout either. Scriptlets are not supposed to be noisy. Sure, I understand that part. I still don't think there's any value to leaving the systemd-run output in the transaction output. I'm genuinely curious what value you see in having these "Running as unit: run-*.service" lines in the output. I can see wanting to know what was happening if one of them hangs or causes errors, but the way this is currently done, the only error output we'd see is if the systemd-run call itself failed. I care more about error output of any commands which are run as scriptlets, but the output of the systemd service is sent to the logs rather than the terminal already, so I have to look there for output and errors. All I see in the case of the man-db-cache-update scriptlet is that the typical >/dev/null was missed when it was converted to use systemd-run. The scriptlet before was: MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q That is silent by design. The MAN_NO_LOCALE_WARNING=1 was added explicitly to avoid spurious output from the scriptlet in 98f1386 ("suppress potential locale warning when installing with glibc-minimal-langpack - resolves #1314633", 2016-03-14): https://src.fedoraproject.org/rpms/man-db/c/98f13860c7 -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (When asked whether he liked children) "Ah yes...boiled or fried." -- W.C. Fields

Samuel Sieb wrote: There is a lot that is run which is not included in the rpm/dnf output. Including it all would be far too verbose to be useful. Scriptlets are supposed to be silent. The problem wasn't that it was silent. It was that it was a long(ish)-running process that was not suited to run as a scriptlet. It's better done via cron or as it is now as a transient systemd-run service. Anyway, I think the current output is unintentional. Whether the man-db packager maintainers agree or not, I don't know. I do feel confident that this output is a departure from how scriptlets have long behaved and it should be more deliberately and consistently designed if it's going to be kept. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Future, n. That period of time when our affairs prosper, our friends are true and our happieness is assured. -- Ambrose Bierce, "The Devil's Dictionary"

Ralf Corsepius wrote: I'm certainly not here to defend systemd's use for seemingly everything. :) All I care about in this situation is quieting the useless and confusing output from the man-db file trigger scriptlet's use of systemd-run. Doing that is a good step and doesn't interfere at all with subsequent work to improve the output from rpm/dnf while handling these transaction triggers, scriptlets, etc. It may well be better to have more defaults in the rpm transaction to alert the user when it's running triggers or something, but that is something which most likely needs to happen in rpm/dnf rather than in this particular scriptlet. What we have here is the output of a scriptlet calling: /usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update We're only getting systemd-run/systemctl output, which is of very dubious value (and that value only goes down as more scriptlets run via this method). Knowing that a file trigger was running the man-db scriptlet would be better, but that's a slightly different matter. -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ninety percent of everything is crap. -- Sturgeon's Law