Description of problem: This seems odd, but at the end of shutdown kdm seems restarted. I first thought it's just vga garbage, but there is also "working clock" mouse cursor and if I change username in kdm before shutdown kdm during shutdown has the username prefilled to default value so it's not just a garbage How reproducible: happens every time Steps to Reproduce: 1.boot to kdm, no login 2.menu->shutdown->reboot OR ctrl-alt-f2, log in as root, reboot 3.some text info about system being shut down Actual results: kdm shows again (and working) just before shutdown for about 1-2 seconds Expected results: no kdm before shutdown
Please try initscripts-9.19-1 when it's available (it *shouldn't* fix this, but it may change it slightly.)
I'm getting the same behaviour with gdm on the systemd Test Day LiveCD ISO and subsequent hard disk installed system.
Same here. kdm is restarted 3 or 4 times during shutdown process. systemd-9-3.fc14.i686 initscripts-9.19-1.fc14.i686
(In reply to comment #1) > Please try initscripts-9.19-1 when it's available (it *shouldn't* fix this, but > it may change it slightly.) tried but no (or not big enough) change
I see the problem in stopping target. graphical.target/stop and multi-user.target/stop is correctly added to transaction but stop on target only stops target but not wanted services/targets which were started on target start.
Hmm, by default all units get a Conflicts to shutdown.target and hence should be pulled down as part of that. I'll have a close look on what is going on here tomorrow.
Does https://bugzilla.redhat.com/show_bug.cgi?id=630935#c9 help?
confirm that I see this too, this seems like a polish issue that should really be fixed at least for final. Marking 'needinfo' for Bill's q.
After updating to the following package versions, gdm is no longer *visibly* restarting at shutdown for me: initscripts-9.20-1.fc14.x86_64 If I'm reading the diff referred to in comment 7 correctly, then adding "Requires=shutdown.target" to the killall.service file seems to have fixed it.
*** This bug has been marked as a duplicate of bug 630935 ***