Bug 1003147 - RFE: visible notification for the user when important services fail to start
RFE: visible notification for the user when important services fail to start
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On: 1008085
  Show dependency treegraph
Reported: 2013-08-31 02:57 EDT by hanishkvc
Modified: 2014-06-18 13:35 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-18 13:35:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Contains outputs of some potentially useful commands involving systemctl, systemd-analyze and iptables (19.42 KB, text/plain)
2013-08-31 02:57 EDT, hanishkvc
no flags Details

  None (edit)
Description hanishkvc 2013-08-31 02:57:08 EDT
Created attachment 792373 [details]
Contains outputs of some potentially useful commands involving systemctl, systemd-analyze and iptables

If for some reason firewalld fails to start, the user is not notified about the same. Which I consider a critical bug, because the system is running without the firewall enabled, even thou the user will think the firewall is running.

I assume this is a failure between SystemD and NotificationDaemon handshaking to show critical errors to the end user.

How reproducible: AND Steps to Reproduce:

Not sure, noticied this issue when booting the system today. But I feel if one simulates a firewalld failure in any way possible, this situation could occur.

Additional info:
Comment 1 Lennart Poettering 2013-09-12 15:13:43 EDT
So, what does "systemctl status firewalld.service" say? I don't see that output in your attachment...
Comment 2 hanishkvc 2013-09-14 02:44:35 EDT
The reason I didn't explicitly include systemctl status firewalld.service was as systemctl --failed and systemctl --list-units already showed that firewalld.service had failed. However I do see that systemctl status may also give some reason has to why it failed. I am attaching the out with this comment below.

***N*** systemctl-status-firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: failed (Result: timeout) since Sat 2013-09-14 12:02:49 IST; 6min ago
 Main PID: 372
   CGroup: name=systemd:/system/firewalld.service

NOTE: Even this boot underwhich I am writing this comment has also resulted in a failure with Firewall starting. And no notification to me.
Comment 3 hanishkvc 2013-09-14 02:49:29 EDT
AND inturn doing a explicit/manual 

systemctl restart firewalld.service 

DOES bring the firewall up.

firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Sat 2013-09-14 12:17:02 IST; 6s ago
 Main PID: 1647 (firewalld)
   CGroup: name=systemd:/system/firewalld.service
           └─1647 /usr/bin/python /usr/sbin/firewalld --nofork --nopid

Sep 14 12:17:02 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall daemon.
Comment 4 Zbigniew Jędrzejewski-Szmek 2013-09-14 09:47:04 EDT
There are two part to this bug: one is that firewalld failed to start, and the second is notifying the user about that. If the firewalld not starting is still a problem, please start a new bug against firewalld. Let's make this one only about the missing notification.

It would be nice to show status in the graphical session notification area, when systemd notices that some services failed to start, or hit an error later on. Gnome people are working on a log tool for the journal, but this is something different. I guess that if the gnome-shell screen showed a notification about failed services like it does for abrt that would be nice. So far we are not only missing the applet to do that (obviously), but we also don't have a graphical tool that we could launch after the user clicks on the notification. But when the gnome journal thing is ready, we could launch it from such a notification, with messages filtered to the ones pertaining to the failed service.
Comment 5 Michal Sekletar 2013-09-14 11:09:46 EDT
IIRC for Type=dbus services we fork off the main process for the service and we wait for bus name to appear. In your case start of service failed because of timeout. Can you please verify that dbus service gets started correctly. It looks ok according to output from list-units, but anyway... I am trying to find out why timeout happened in the first place.

Please attach debugging output, i.e output of journalctl from boot when bugs occurs. See article [1] on how to debug boot issues. Thanks.

[1] http://freedesktop.org/wiki/Software/systemd/Debugging/
Comment 6 Lennart Poettering 2014-02-23 11:42:12 EST
systemd 209 now will enable boot-time output as soon as a unit takes too long to start up.
Comment 7 Zbigniew Jędrzejewski-Szmek 2014-06-18 13:35:38 EDT
systemd-209 was released a while ago...

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