Bug 812555

Nothing there sounds kernel related.  I've moved it to the general distribution component for now.  This might be gdm or systemd, but I don't know which.

yum update showed a new kernel (and other stuff), so I tried rebooting to that
I still get the same behavior if I don't boot single, but now after boot single
and move to runlevel 3 I can login as user.  Lots of things are working better
but still finding things not quite right.
BTW, new kernel is kernel-3.3.1-5.fc16.x86_64

A few more details - when login as user I see some new abrt entries.
Rather than report them directly, I copy paste some details here.

cmd line:
python /usr/bin/printer-applet

reason:
connection.py:630:call_blocking:DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file

backtrace:
connection.py:630:call_blocking:DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file

Traceback (most recent call last):
  File "/usr/bin/printer-applet", line 1163, in <module>
    applet = JobManager()
  File "/usr/bin/printer-applet", line 300, in __init__
    notification = NewPrinterNotification(bus, self)
  File "/usr/bin/printer-applet", line 1052, in __init__
    bus_name = dbus.service.BusName (PDS_OBJ, bus=bus)
  File "/usr/lib/python2.7/site-packages/dbus/service.py", line 129, in __new__
    retval = bus.request_name(name, name_flags)
  File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 306, in request_name
    'su', (name, flags))
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.424" is not allowed to own the service "com.redhat.NewPrinterNotification" due to security policies in the configuration file

Local variables in innermost frame:
byte_arrays: False
self: <dbus._dbus.SystemBus (system) at 0x2e0c6b0>
args: ('com.redhat.NewPrinterNotification', 0)
utf8_strings: False
bus_name: 'org.freedesktop.DBus'
get_args_opts: {'byte_arrays': False, 'utf8_strings': False}
object_path: '/org/freedesktop/DBus'
timeout: -1.0
signature: 'su'
dbus_interface: 'org.freedesktop.DBus'
message: <dbus.lowlevel.MethodCallMessage object at 0x2fa7600>
method: 'RequestName'

Second one seems harder to copy/paste data from.
Problem description is that /usr/lib/jvm/java-1.7.0.../java was killed by signal 6 (sigabrt)

This looks like it's related to abrt itself.  Here's stuff from /var/log/messages that seems related.

Apr 15 12:04:28 number11 abrtd: Directory 'ccpp-2012-04-15-12:04:26-11391' creation detected
Apr 15 12:04:28 number11 abrt[11403]: Saved core dump of pid 11391 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java) to /var/spool/abrt/ccpp-2012-04-15-12:04:26-11391 (110288896 bytes)
Apr 15 12:04:32 number11 abrtd: New problem directory /var/spool/abrt/ccpp-2012-04-15-12:04:26-11391, processing

Seems to be a problem with gdm. Reassigning.

Please attach /var/log/messages from when this happens.

You want the entire boot transcript from /var/log/messages?
I will attach what I think is the first failure - 
I hope there's not too much sensitive info in it.

Created attachment 577803 [details]
/var/log/messages transcript from first boot failure

What does this command say?:
systemctl status systemd-tmpfiles-setup.service

This is in the new kernel after I login as user and startx:


$ systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
	  Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
	  Active: [1;31mfailed[0m since Sun, 15 Apr 2012 01:00:48 -0700; 2 days ago
	Main PID: 1154 (code=exited, status=127)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Is this supposed to be deleting files from /tmp ?  Can I turn it off?  Or at
least control it?
I've disabled it for now -  replaced /bin/systemd-tmpfiles with a shell script that does nothing but record that it was called.  It's hard to believe that has anything to do with all of these symptoms.

(In reply to comment #8)
> $ systemctl status systemd-tmpfiles-setup.service
> systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
>    Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
>    Active: [1;31mfailed[0m since Sun, 15 Apr 2012 01:00:48 -0700; 2 days ago
>  Main PID: 1154 (code=exited, status=127)
>    CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
> 
> Is this supposed to be deleting files from /tmp ?

It can do that too, but that's not its primary purpose. As its description says, it's meant to "Recreate Volatile Files and Directories". That includes such directories as /run/lock (to which /var/lock should point).

> Can I turn it off?

Don't.

> Or at least control it?

man tmpfiles.d

> I've disabled it for now -  replaced /bin/systemd-tmpfiles with a shell script
> that does nothing but record that it was called.

Please undo that.

ok, it's undone.  Now I suppose you want me to reboot?  Perhaps to the older
kernel to see whether it all works there too?
It seems that my change didn't hurt anything until reboot.

I have to say that it's extremely unfriendly to change the software that I've been using for years (tmpwatch config set NOT to delete files from /tmp)
to start deleting my files.  I wonder what else has been changed behind my back.

Yes, if you would, reboot and pass the following parameters on the kernel command line:
 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

After booting save the output of the 'dmesg' command and attach it. Thanks.

Created attachment 578159 [details]
dmesg

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.