Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1871327 - systemd-analyze break system
Summary: systemd-analyze break system
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-22 11:21 UTC by Martin
Modified: 2020-09-08 17:04 UTC (History)
10 users (show)

Fixed In Version: systemd-246.4-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-08 17:04:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journalctl -o short-unix --no-hostname -b (deleted)
2020-08-24 17:04 UTC, Martin
no flags Details

Description Martin 2020-08-22 11:21:38 UTC
Description of problem:
when I try run systemd-analyze show some fail(unit service is changing time to time)
[martin@localhost SOURCES]$ sudo systemd-analyze blame
[sudo] heslo pro martin: 
Failed to get timestamp properties of unit nftables.service: Spojení bylo příliš dlouho neaktivní

after that sudo take too long or fail, sometimes system freeze

Version-Release number of selected component (if applicable):
systemd-246.1-1.fc33.x86_64
sudo-1.9.1-3.fc33.x86_64

How reproducible:
often

Steps to Reproduce:
1.run systemd-analyze blame
2.try something else (sudo dnf update, run game in steam ...)
3.system freeze or command fail/take too long when is something do

Actual results:
system got fail after  systemd-analyze blame

Expected results:
system running ok

Additional info:

Comment 1 Martin 2020-08-24 17:04:21 UTC
Created attachment 1712402 [details]
journalctl -o short-unix --no-hostname -b

Comment 2 Artem 2020-08-25 18:07:32 UTC
Can confirm this. After doing 'systemd-analyze blame' system dying. Can't even reboot.

❯ systemd-analyze blame

  Failed to get timestamp properties of unit sys-devices-pci0000:00-0000:00:11.0-ata4-host3-target3:0:0-3:0:0:0-block-sdb.device: Connection timed out


Version-Release number of selected component (if applicable):
systemd-246.1-1.fc33.x86_64

Comment 3 Martin 2020-08-25 20:49:39 UTC
I set "timedatectl set-local-rtc 0" now is working

Comment 4 Zbigniew Jędrzejewski-Szmek 2020-08-26 13:44:10 UTC
After some upstream discussion we found one suspicious patch. In
https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/1635482/
there's build systemd-246.3-2 that reverts the patch. It is otherwise the same as systemd-246.3-1 in rawhide/f33
right now. It would be great if someone who can reproduce the issue checked whether it still occurs
with systemd-246.3-2. (And if *not*, then whether it still occurs with systemd-246.3-1.)

Comment 5 Artem 2020-08-26 14:33:36 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/1635482/

This requires rebuilt i guess? Please check copr build and i'll test it.

Also tried 'systemd-246.3-1' but issue is still here, yep.

Comment 6 Martin 2020-08-26 14:37:06 UTC
with systemd-246.3-1 has the same behavior, fail with "RTC in local TZ: YES"(fc33 default) ,works ok with "RTC in local TZ: NO"

Comment 8 Zbigniew Jędrzejewski-Szmek 2020-08-26 15:37:19 UTC
(In reply to Martin from comment #6)
> with systemd-246.3-1 has the same behavior, fail with "RTC in local TZ:
> YES"(fc33 default) ,works ok with "RTC in local TZ: NO"

Hmm, OK. So maybe it's that we load with a wrong time, store the mtime, and keep trying to load
the unit because we think the modification time is in the future.

Comment 9 Martin 2020-08-26 15:53:03 UTC
systemd-246.3-2 behavior just flipped sytem dies if "RTC in local TZ: NO" and works "wellL" with "RTC in local TZ: YES"

Comment 10 Martin 2020-08-26 16:04:49 UTC
just in case if someone try reproduce.
Virtual Machine(KVM efi) is not affected, just bare metal (for me).

Comment 11 Artem 2020-08-26 16:13:39 UTC
Tested and unfortunately issue is still here in 'systemd-246.3-2'.

Comment 12 Martin 2020-08-26 17:17:14 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> (In reply to Martin from comment #6)
> > with systemd-246.3-1 has the same behavior, fail with "RTC in local TZ:
> > YES"(fc33 default) ,works ok with "RTC in local TZ: NO"
> 
> Hmm, OK. So maybe it's that we load with a wrong time, store the mtime, and
> keep trying to load
> the unit because we think the modification time is in the future.

If its related,not sure
with systemd-246.3-2 show
chronyd[809]: System clock wrong by 7200.644458 seconds, adjustment started
chronyd[809]: System clock was stepped by 7200.644458 seconds

Comment 13 Fedora Update System 2020-09-02 11:07:19 UTC
FEDORA-2020-2255b438a2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2

Comment 14 Martin 2020-09-02 15:52:31 UTC
systemd-246.4-1.fc33.x86_64 looks works ok now

Comment 15 Fedora Update System 2020-09-02 16:20:22 UTC
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2255b438a2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2020-09-08 17:04:24 UTC
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.