Bug 1244023

Created attachment 1052863 [details]
File: backtrace

Created attachment 1052864 [details]
File: cgroup

Created attachment 1052865 [details]
File: core_backtrace

Created attachment 1052866 [details]
File: dso_list

Created attachment 1052867 [details]
File: environ

Created attachment 1052868 [details]
File: limits

Created attachment 1052869 [details]
File: maps

Created attachment 1052870 [details]
File: mountinfo

Created attachment 1052871 [details]
File: namespaces

Created attachment 1052872 [details]
File: open_fds

Created attachment 1052873 [details]
File: proc_pid_status

Journal messages (the first three probably aren't relevant, but just including for context):

Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): Gtk-CRITICAL **: Error building template class 'GisBubbleWidget' for an instance of type 'GisBubbleWidget': .:2:910 Can't use <style> here
Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): Gtk-CRITICAL **: gtk_label_set_label: assertion 'GTK_IS_LABEL (label)' failed
Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed
Jul 16 16:26:23 localhost.localdomain dbus[743]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service'
Jul 16 16:26:23 localhost.localdomain dbus[743]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.timedate1.service': Unit timedatex.service failed to load: File exists. See system logs and 'systemctl status timedatex.service' for details.
Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: ** (gnome-initial-setup:1519): ERROR **: Failed to create proxy for timedated: Error calling StartServiceByName for org.freedesktop.timedate1: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit timedatex.service failed to load: File exists. See system logs and 'systemctl status timedatex.service' for details.

Proposing as an Alpha blocker: " A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.
A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." - https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

timedatex-0.3-2.fc23

Running /usr/sbin/timedatex directly appears to succeed, but running 'systemctl start timedatex.service' fails with the same error as seen in the journal ("Unit timedatex.service failed to load: File exists.")

This seems to be caused in some way by a conflict with systemd-timedated.service . This works:

mv /lib/systemd/system/systemd-timedated.service /tmp
systemctl daemon-reload
systemctl restart timedatex.service

systemd-timedated.service and timedatex.service have identical BusName and CapabilityBoundingSet lines:

BusName=org.freedesktop.timedate1
CapabilityBoundingSet=CAP_SYS_TIME

Note that systemd-timedated.service doesn't have to be *running* for the bug to happen - it only has to be *there* ('loaded' in systemd parlance).

this is clearly screwing up systemd. I'm not sure if it's because units aren't allowed to do that, or because they should be allowed to but systemd has a bug in this scenario.

I'm also not sure whether it's considered a bug in g-i-s if it crashes when timedatex.service fails to start, or not. If that in itself is a bug in g-i-s, I can file a separate bug for the timedatex/systemd-timedated problem. If the crash itself isn't considered a bug, we can re-assign this to timedatex or systemd.

The 'timedatex.service fails' part of this seems to be a regression of some sort in systemd. In Fedora 22 (systemd 219) the setup is the same - both timedatex.service and systemd-timedated.service exist, and both specify the same BusName and CapabilityBoundingSet - but you can start either one up fine. In fact you can even start both at once (Pete knows which one gets to respond to dbus requests when you do that...)

I submitted an upstream bug for the systemd portion of this: https://github.com/systemd/systemd/issues/609

Discussed at today's blocker review meeting [1].

This bug was accepted as Alpha blocker - This bug is a clear violation of the following Alpha criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-07-20/

So, the plot thickens: Lennart says systemd isn't going to fix this, which means I guess it's up to timedatex to do something about it. I filed https://github.com/mlichvar/timedatex/issues/2 and I guess I'll re-assign this to timedatex.

Ok, it looks like we need to mask systemd-timedated in timedatex, at least for now.

There might be a cleaner approach. If systemd-timedated had its own subpackage, timedatex could conflict with it at rpm level, so there would be always only one timedated implementation installed. The last attempt to split the systemd package didn't went too well, however.

timedatex-0.3-3.fc23 now includes a symlink that masks the systemd-timedated service.

Thanks for the investigation, Adam.