| Summary: | systemd changing runlevel works poorly | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Dick Gevers <dvgevers> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | dmorganec, mageia, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | initscripts | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 2120 | ||
|
Description
Dick Gevers
2011-11-02 21:46:31 CET
Dick Gevers
2011-11-02 21:47:36 CET
Blocks:
(none) =>
2120 s/prblem/problem @ Dick Is the problem still there in current cauldron (version systemd-37-13.mga2) ? When in grub menu, after choosing F3 and default, do I need to add "systemd.unit=multi-user.target", or is adding "3" enough? In updated cauldron I tried with "3", that gave some systemctl failed messages and then booting stopped. CC:
(none) =>
dmorganec, marja11 Marja: I will test it again, but I believe yes. '3' is supposed to work, but only to be compatible with sysvinit. The 'systemd...' is as per systemd documentation. See http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions and 'man systemd' --> KERNEL COMMAND LINE m.v.g. My 'believe' was wrong (I am glad to say), there is improvement: * Changing from 5 to 1 (tried twice): not okay: same error as before. Also, the advertised "type Control-D to continue" is not working. * Changing from 1 to 3: okay now. * Changing from 3 to 5 (tried twice with same result): I get there okay, but I get an error (graphical display with odd font) upon logging into xfce4 with kdm, reading: WARNING CANNOT OPEN CONSOLEKIT SESSION. UNABLE TO OPEN SESSION. FAILED TO CONNECT TO SOCKET /CAR/RUN/DBUS/SYSTEM_BUS_SOCKET. NO SUCH FILE OR DIRECTORY. (All needed directories directly below "/" except /boot are on the same partition). Indeed terminal started from the desktop shows console-kit-daemon is not running. * Booting into 1: okay, works (although after the login prompt appear the words "Started singel service", making the prompt disappear. Can login after: [ Enter ] Login incorrect though. * Booting into 3: I get there okay again, but on the login prompt appears several bootup messages disturbing the entering of the userid. After a couple of [ Enter ] the login prompt is quiet and working. BTW, above is with kernel-desktop-3.1.2-0.rc1 on latest laptop. I hadn't gotten around to installing latest kernel. But Cauldron is otherwise up to date. I stopped trying to test because I'm not sure I know enough and because atm, the time is missing to learn more. first cc'ing colin CC:
(none) =>
mageia and now assigning to maintainer Assignee:
bugsquad =>
dmorganec what about this bug with systemd 40 ? Hardly any improvement, I'm afraid: Booting into 1: Prints quote Welcome to rescue mode. Use "systemctl default" or ^D to activate default mode. Failed to issue method call: Transaction is destructive unquote There is no login prompt. Entering the root password deos not give access to rescue mode (nothing happens). Booting into 3: okay now. Changing from 5 to 1: unchanged from original report. Changing from 3 to 5: seems to work okay (graphical target appears). But consolekit has not started normally. After logging in there appears a warning quote Warning, Cannot open ConsoleKit session: Unable to open session: Failed to connect to /var/run/dbus/system_bus_socket. No such file or directory. unquote and indeed ps shows consolekit-daemon is not running at all.
Marja Van Waes
2012-02-11 16:51:54 CET
Source RPM:
systemd-37-8.mga2 =>
systemd-40-2.mga2.src.rpm can you look at:
systemctl status dbus.socket
output when going from 3 to 5?
But I wonder if this is a bug in systemd itself.
As dbus is socket activated in systemd, it should be perfectly possible to start console-kit before dbus itself is actually started provided systemd has already enumerated all the .socket files wanted by the next target and has opened all the sockets... and it seems this isn't happening when switching from 3 to 5 as otherwise systemd itself would have created (and started listening on) the /var/run/dbus/system_bus_socket file...
That said, dbus should be started in runlevel3... (it's wanted by multi-user.target) and as such should already be available before switching to 5... so actually this is quite strange.
Did you boot direct to 3 then swtich to 5? If so, can you check when booting direct to 3 that dbus is actually running and the system_bus_socket file does is exist and who is actually listening on it?
e.g.:
[colin@jimmy ~]$ sudo fuser -v /var/run/dbus/system_bus_socket
USER PID ACCESS COMMAND
/var/run/dbus/system_bus_socket:
messagebus 1867 F.... dbus-daemon
Let's see: booting into runlevel 3: systemctl status dbu.socket dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (lib/systemd/system/dbus.socket; static) Active: active (running) since ....[date]; ..min .. s ago CGroup: name=systemd:/system/dbus.socket but: fuser -v /var/run/dbus/system_bus_socket Specified filename /var/run/system_bus_socket does not exist. Chaging to runlevel 5 and logging in: Same warning as before! and now still: systemctl status dbu.socket dbus.socket - D-Bus System Message Bus Socket Loaded: loaded (lib/systemd/system/dbus.socket; static) Active: active (running) since ....[date]; ..min .. s ago CGroup: name=systemd:/system/dbus.socket But consolekit is not running BTW this is on a different Cauldron machine than my last comments: but the results appear to be similar! Hmm, that's just weird... It's almost like something removes the socket after it's created :s I'll try and reproduce but not sure when I'll get time... hopefully on Wednesday. This should be resolved in latest initscripts package. Basically the same as was reported in bug #4744 (I thought they were the same bugs, but it did seem kinda "new" when I knew I'd read the report a while ago!) Anyway, like I say should be fixed now. Status:
NEW =>
RESOLVED |