Re: What is this gibberish?

[Todd Zullinger]

Ralf Corsepius wrote:
> On 02/04/2018 08:34 AM, Todd Zullinger wrote:
> 
>> 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.
> And does this actually work?
> 
> I recently was facing situations where this mandb stuff hit midst of
> shutdown, when all mounted files already where unmounted, delaying shutdowns
> be some 10-15mins.
> 
> I haven't investigated, but I was inclined to blame systemd's unreliabily
> and lack of robustness ;)

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.

>> Anyway, I think the current output is unintentional.
> I think, the output needs to be more verbose and consider the current output
> to be non-helpful.

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



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Ralf Corsepius]

On 02/04/2018 08:34 AM, Todd Zullinger wrote:


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.

And does this actually work?

I recently was facing situations where this mandb stuff hit midst of 
shutdown, when all mounted files already where unmounted, delaying 
shutdowns be some 10-15mins.


I haven't investigated, but I was inclined to blame systemd's 
unreliabily and lack of robustness ;)



Anyway, I think the current output is unintentional.
I think, the output needs to be more verbose and consider the current 
output to be non-helpful.


Ralf
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> It lets me know that something else was run, just like there's a line saying
> that it's running a scriptlet for package whatever.  As I mentioned, I would
> much prefer that there was some part of that line that said what the unit is
> for, but at least with that line I know that it's happening and I can check
> the logs if necessary.

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.

>> 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
> 
> This being silent ended up being a problem.  mandb took a long time to run
> and there was no explanation on why the dnf transaction appeared to be hung
> for several minutes.  It would have been good if there had been some output
> saying that mandb was being run.  Sure you might be able to switch consoles
> and run "ps" if you know about that, but this would have been easier.

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"



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Samuel Sieb]

On 02/03/2018 09:30 PM, Todd Zullinger wrote:

Samuel Sieb wrote:

How is it not useful?  I'm happy to be aware of that part of the
transaction.  It would certainly be more useful if there was some indication
of what specifically it was for.


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 lets me know that something else was run, just like there's a line 
saying that it's running a scriptlet for package whatever.  As I 
mentioned, I would much prefer that there was some part of that line 
that said what the unit is for, but at least with that line I know that 
it's happening and I can check the logs if necessary.



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


This being silent ended up being a problem.  mandb took a long time to 
run and there was no explanation on why the dnf transaction appeared to 
be hung for several minutes.  It would have been good if there had been 
some output saying that mandb was being run.  Sure you might be able to 
switch consoles and run "ps" if you know about that, but this would have 
been easier.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> On 02/03/2018 05:57 PM, Todd Zullinger wrote:
>> The unit tasks are logged, so you can see them with
>> journalctl or in syslog.  (Not that it's at all ideal to
>> have to look around to find what may have caused this
>> less-than-useful output.)
> 
> How is it not useful?  I'm happy to be aware of that part of the
> transaction.  It would certainly be more useful if there was some indication
> of what specifically it was for.

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.

>> The man-db-cache-update service checks /etc/sysconfig/man-db
>> and if the variable SERVICE is not 'no' it runs.  So it
>> should be possible to disable this proactive updating of the
>> man-db if desired.
> 
> This mandb run has always been done.  The change now to running it as a
> service is because when it was being run as part of the main process, it was
> taking a very long time sometimes and holding up the rest of the
> transaction.  Now, it's running separately and is not waited for.

Sure, I understand that part.  I still don't think there's
any value to leaving the systemd-run output in the
transaction output.

> Personally, I hope it's not accepted and I expect there are other parts that
> are using or will use this method.

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



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Tom Horsley wrote:
> On Sun, 4 Feb 2018 10:17:10 +0800
> Ed Greshko wrote:
> 
>> 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.  :-) :-)  
> 
> And then the secret society can cause great amusement by
> utterly changing the GUI in every release to see how long it
> takes people to figure out the new one just as they
> got used to the old one :-).

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



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Samuel Sieb]

On 02/03/2018 05:57 PM, Todd Zullinger wrote:

The unit tasks are logged, so you can see them with
journalctl or in syslog.  (Not that it's at all ideal to
have to look around to find what may have caused this
less-than-useful output.)


How is it not useful?  I'm happy to be aware of that part of the 
transaction.  It would certainly be more useful if there was some 
indication of what specifically it was for.



The man-db-cache-update service checks /etc/sysconfig/man-db
and if the variable SERVICE is not 'no' it runs.  So it
should be possible to disable this proactive updating of the
man-db if desired.


This mandb run has always been done.  The change now to running it as a 
service is because when it was being run as part of the main process, it 
was taking a very long time sometimes and holding up the rest of the 
transaction.  Now, it's running separately and is not waited for.



I submitted a patch to quiet this output:

 https://src.fedoraproject.org/rpms/man-db/pull-request/5

If that's accepted then we'll eventually stop seeing this
anytime an rpm installs or removes man pages.


Personally, I hope it's not accepted and I expect there are other parts 
that are using or will use this method.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Tom Horsley]

On Sun, 4 Feb 2018 10:17:10 +0800
Ed Greshko wrote:

> 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.  :-) :-)  

And then the secret society can cause great amusement by
utterly changing the GUI in every release to see how long it
takes people to figure out the new one just as they
got used to the old one :-).
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Ed Greshko]

On 02/04/18 09:57, Todd Zullinger wrote:
> Samuel Sieb wrote:
>> On 02/02/2018 04:31 AM, Tom Horsley wrote:
>>> Just did a dnf update, this comes out:
>>>
>>> ...
>>>Running scriptlet: firefox-58.0.1-1.fc27.x86_64 
>>> 18/18
>>>Running scriptlet: firefox-58.0-4.fc27.x86_64   
>>> 18/18
>>> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
>>> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>>>Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   
>>> 1/18
>>>Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   
>>> 2/18
>>> ...
>>>
>>> Running as unit? Huh?
>> 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".
> The unit tasks are logged, so you can see them with
> journalctl or in syslog.  
Snip
> Just knowing what it is is enough for me, I
Snip
>  Plus, the
> output we get now is effectively worthless. :)
>
> I submitted a patch to quiet this output:
>
> https://src.fedoraproject.org/rpms/man-db/pull-request/5
>
> If that's accepted then we'll eventually stop seeing this
> anytime an rpm installs or removes man pages.
>
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



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> On 02/02/2018 04:31 AM, Tom Horsley wrote:
>> Just did a dnf update, this comes out:
>> 
>> ...
>>Running scriptlet: firefox-58.0.1-1.fc27.x86_64 
>> 18/18
>>Running scriptlet: firefox-58.0-4.fc27.x86_64   
>> 18/18
>> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
>> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>>Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   
>> 1/18
>>Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   
>> 2/18
>> ...
>> 
>> Running as unit? Huh?
> 
> 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".

The unit tasks are logged, so you can see them with
journalctl or in syslog.  (Not that it's at all ideal to
have to look around to find what may have caused this
less-than-useful output.)

As you said, the man-db package includes a transaction
trigger which runs the man-db-cache-update service when any
package in the transaction adds or removes files from
/usr/share/man:

$ rpm -q --filetriggers man-db
transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

# update cache
transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

The man-db-cache-update service checks /etc/sysconfig/man-db
and if the variable SERVICE is not 'no' it runs.  So it
should be possible to disable this proactive updating of the
man-db if desired.

Just knowing what it is is enough for me, I think.  It
worried me the first time I noticed it when updating a
package I built in a COPR, since I knew there were no
systemd scriptlets in that package.

I'm not sure why the man-db trigger scriptlets don't direct
output to /dev/null like most scriptlets.  It seems like
they should.  The systemd service call is logged, so if
there's a problem it should be visible in syslog.  Plus, the
output we get now is effectively worthless. :)

I submitted a patch to quiet this output:

https://src.fedoraproject.org/rpms/man-db/pull-request/5

If that's accepted then we'll eventually stop seeing this
anytime an rpm installs or removes man pages.

-- 
Todd
~~
Man was made at the end of the week's work when God was tired.
-- Mark Twain



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Fred Erickson]

On Fri, 2 Feb 2018 07:31:03 -0500
Tom Horsley  wrote:

> Just did a dnf update, this comes out:
> 
> ...
>   Running scriptlet:
> firefox-58.0.1-1.fc27.x86_64 18/18 Running
> scriptlet: firefox-58.0-4.fc27.x86_64   18/18
> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
> Running as unit: run-r329e01978cfe43258a05456898834edb.service
> Verifying:
> GraphicsMagick-1.3.28-1.fc27.x86_64   1/18
> Verifying:
> GraphicsMagick-c++-1.3.28-1.fc27.x86_64   2/18 ...
> 
> Running as unit? Huh?

You are not alone. Similar situation here:

Running scriptlet: firefox-58.0.1-1.fc27.x86_64 122/122 
Running scriptlet: dnsmasq-2.78-1.fc27.x86_64   122/122 
Running as unit: run-r4091355e6eda403ab619301c6b4167a2.service 
Running as unit: run-r84d2c3fe76c944dda6612bf577907e27.service 
Running scriptlet: vim-common-2:8.0.1438-1.fc27.x86_64  122/122 
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Samuel Sieb]

On 02/02/2018 04:31 AM, Tom Horsley wrote:

Just did a dnf update, this comes out:

...
   Running scriptlet: firefox-58.0.1-1.fc27.x86_64 18/18
   Running scriptlet: firefox-58.0-4.fc27.x86_64   18/18
Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
Running as unit: run-r329e01978cfe43258a05456898834edb.service
   Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   1/18
   Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   2/18
...

Running as unit? Huh?


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".

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Matthew Miller]

On Fri, Feb 02, 2018 at 07:31:03AM -0500, Tom Horsley wrote:
>   Running scriptlet: firefox-58.0.1-1.fc27.x86_64 
> 18/18 
>   Running scriptlet: firefox-58.0-4.fc27.x86_64   
> 18/18 
> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>   Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   
> 1/18 
>   Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   
> 2/18 
> ...
> Running as unit? Huh?

I don't know what exactly is going on, or why the unit has such a
strange name, but a "unit" is systemd-ese to describe all of the
various individual things it can work with -- services, devices, mount
points, sockets, etc. See `man systemd.unit`.

-- 
Matthew Miller

Fedora Project Leader
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

What is this gibberish?

[Tom Horsley]

Just did a dnf update, this comes out:

...
  Running scriptlet: firefox-58.0.1-1.fc27.x86_64 18/18 
  Running scriptlet: firefox-58.0-4.fc27.x86_64   18/18 
Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
Running as unit: run-r329e01978cfe43258a05456898834edb.service
  Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   1/18 
  Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   2/18 
...

Running as unit? Huh?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

vtnr? seat0? What does this gibberish mean?

[Tom Horsley]

I've started getting lots of these in my logs:

crond: pam_systemd(crond:session): Ignoring vtnr 0 for  which is not seat0
pam_systemd(sshd:session): Ignoring vtnr 0 for  which is not seat0

I'm sure I can just ignore them, but what the heck do they mean?
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vtnr? seat0? What does this gibberish mean?

[poma]

On 03.03.2014 15:18, Tom Horsley wrote:
 I've started getting lots of these in my logs:
 
 crond: pam_systemd(crond:session): Ignoring vtnr 0 for  which is not seat0
 pam_systemd(sshd:session): Ignoring vtnr 0 for  which is not seat0
 
 I'm sure I can just ignore them, but what the heck do they mean?
 

virtual terminal number,
- pam_systemd: Ignore vtnr when seat != seat0
http://cgit.freedesktop.org/systemd/systemd/commit/src/login/pam-module.c?id=d7353ef6095f5e7db63d9cc898c7134b64482550

# grep vtnr /var/log/secure* | wc -l
1048

- pam_systemd is spewing the logs
https://bugzilla.redhat.com/show_bug.cgi?id=1070970


poma


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org