Systemd - problems, questions.

[nimnull22]

As long we all suffer from "systemd experiment", I decide that may be it will be better if we discuss about it in one thread.

So. I would like to say about my problems.
1. Systemd is not default - I am happy about it and I know how to change it, but not now, now it is dangerous.
2. After last update "Fedora 14 updates-testing report" from Thu Aug 12 20:03:02 UTC 2010 systemd-7-3.fc14, I was unable change tty with "ctrl+alt"F1, F2...
Also Xorg used 85-90% of CPU.
3. Unable to "restart" and "shut down".


Solution is to add "init=/sbin/upstart" to the GRUB kernel line, it disables systemd and enables upstart, which fully works (at least for me).

[GoinEasy9]

I tried that nimnull22, and upstart didn't work for me. Look at the last posts on my Shutdown thread, there is a link to a bugzilla that shows that the problem is upower/gnome-panel, or at least that's what they are assuming.

---------- Post added at 03:05 PM CDT ---------- Previous post was at 03:03 PM CDT ----------

Here's the link to the BZ
https://bugzilla.redhat.com/show_bug.cgi?id=623257

[nimnull22]

Sorry, I alway forgot that most of you use gnome, but I - XFCE. Sorry about that, I have not checked Gnome after last update.
Sorry for confuse you.

[GoinEasy9]

Doesn't XFCE use gdm? According to the anaconda install log, upower came in with gdm during install.

[nimnull22]

Doesn't XFCE use gdm? According to the anaconda install log, upower came in with gdm during install.

I probably confused all of you ones again. Long time ago I installed SLIM as a display manager, and looks like got used to it. So now, I really do not notice that in reality, display manager should be different, slim also starts GNOME on me laptop.

I use XFCE + SLIM.
Now I realize how many combinations can be.
But, to summarize all thoughts, xfce + slim + upstart works fine: restart, shutdown and logout. And I have used this combination (xfce + slim + upstart), since I installed rawhide.

[nimnull22]

OK, it is time to discuss systemd-8-3, which updated yesterday.
1. I can't find where this update was announced on the "test" mail list, may be I missed it.

2. What is really awful with systemd is that I can't change TTY with "ctrl+alt+F key" - neither before X11 starts, nor after it. I use SLIM+XFCE, and I can change tty1-5 with upstart within slim login prompt and of course within X11 under fxce. But with systemd I can't. This is BIG error.

3. Mr. RahulSundaram said about my comments: "It writes something about "invalid" for a few second at the end on the last screen" - he said - "8.3 should fix that warning as well."
Well he was right actually, 8.3 fixed this issue, but in very unusual way (as usual) - now the screen is black - it simply shows nothing. It sounds like - ..... all of you.
I did't like it.

Please, check what I notice. Does only my box behave like this?
Thanks

---------- Post added at 11:26 PM CDT ---------- Previous post was at 10:50 PM CDT ----------

About systemd shutdown empty screen.
May be output was redirected somewhere?

[AdamW]

Switching consoles works fine with GDM+GNOME, sounds like it may be something to do with SLIM (which, btw, the maintainer recently orphaned, complaining about how broken it was:

http://lists.fedoraproject.org/pipermail/devel/2010-August/141900.html

[smr54]

Just for what it is worth, using rawhide,

I'm finding that a lot of minor aggravations with it are gradually getting fixed. For example, about a week ago, using systemd and booting into text mode....

the wpa_supplicant service wouldn't work with selinux set to enforcing
dbus had to be started manually, which meant that
hal had to be started manually.

Just got a chance to upgrade last night, and all three of these issues are now fixed.

I feel that' s a good sign.

[GoinEasy9]

I've been using systemd 8-3 with F14 since it appeared in koji and it seemed to have fixed all of the systemd related problems. I still haven't set up a new rawhide box, so, I haven't been following the packages for F15 in koji as close as I used to. If F15 now has 8-3, I would look elsewhere for the cause of problems, unless your running a specialized network that needs a unique init.

[nimnull22]

Ok, I looked into logs and found next:
After reboot in messages log:
Sep 1 22:15:47 localhost /sbin/mingetty[1019]: tty2: invalid character 0x1c in login name
Sep 1 22:15:52 localhost systemd[1]: getty@tty2.service: main process exited, code=exited, status=1
Sep 1 22:15:52 localhost systemd[1]: getty@tty2.service holdoff time over, scheduling restart.
Sep 1 22:15:52 localhost systemd[1]: Unit getty@tty2.service entered maintenance state.
Sep 1 22:15:57 localhost gnome-keyring-daemon[1260]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Sep 1 22:15:57 localhost gnome-keyring-daemon[1260]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Sep 1 22:15:57 localhost gnome-keyring-daemon[1260]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files

And I can't change tty.


Then I do logout and login. I have only:
Sep 1 22:16:57 localhost gnome-keyring-daemon[1457]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Sep 1 22:16:57 localhost gnome-keyring-daemon[1457]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
Sep 1 22:16:57 localhost gnome-keyring-daemon[1457]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files

Now I can change tty.

Slim log gives me when I can't change tty:
Failed to switch from vt02 to vt03: Input/output error
Failed to switch from vt02 to vt01: Input/output error


I do not think it is really slim's problem.

[nimnull22]

Ok. It works, but not by it self.
I do not know whose problem is it, but to be happy with slim and systemd, one needs to specify on which vt xserver has to be started. Strange but with upstart slim starts X11 on vt7 by default, but with systemd it wont happen - X11 starts on vt1 with all unpleasant consequences.

[AdamW]

We intend for X to start on tty1 in most cases. If slim can't handle that, it's broken.

[nimnull22]

Ok. On my box X11 will start on tty7, and is slim broken or not I don't care.

What I really care of is why systemd starts services which upstart doesn't.
console-kit-log-system-start.service
dev-hugepages.automount

I check dmesg after boot with upstart, there is not any sign of those two.
Why one think that they are necessary? And are they?
Interesting:

"Introduction to ConsoleKit.
The ConsoleKit package is a framework for keeping track of the various users, sessions, and seats present on a system."

Sound like I should never turn it on.

I start to suspect systemd.

---------- Post added at 01:05 PM CDT ---------- Previous post was at 12:35 PM CDT ----------

For example: output of cat /proc/self/mountinfo with upstart:
16 21 0:3 / /proc rw,relatime - proc /proc rw
17 21 0:16 / /sys rw,relatime - sysfs /sys rw,seclabel
18 23 0:5 / /dev rw,relatime - devtmpfs udev rw,seclabel,size=755932k,nr_inodes=188983,mode=755
19 18 0:10 / /dev/pts rw,relatime - devpts devpts rw,seclabel,gid=5,mode=620,ptmxmode=000
20 18 0:17 / /dev/shm rw,relatime - tmpfs tmpfs rw,seclabel
21 1 253:0 / / rw,relatime - ext4 /dev/mapper/VolGroup-lv_root rw,seclabel,barrier=1,data=ordered
22 21 0:13 / /selinux rw,relatime - selinuxfs none rw
23 21 0:5 / /dev rw,relatime - devtmpfs udev rw,seclabel,size=755932k,nr_inodes=188983,mode=755
24 16 0:14 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw
25 21 8:5 / /boot rw,relatime - ext4 /dev/sda5 rw,seclabel,barrier=1,data=ordered
26 16 0:18 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw
27 21 0:19 / /home/vas/.gvfs rw,nosuid,nodev,relatime - fuse.gvfs-fuse-daemon gvfs-fuse-daemon rw,user_id=500,group_id=500
28 17 0:20 / /sys/fs/fuse/connections rw,relatime - fusectl fusectl rw


with systemd:
16 21 0:3 / /proc rw,relatime - proc /proc rw
17 21 0:16 / /sys rw,relatime - sysfs /sys rw,seclabel
18 23 0:5 / /dev rw,relatime - devtmpfs udev rw,seclabel,size=755932k,nr_inodes=188983,mode=755
19 18 0:10 / /dev/pts rw,relatime - devpts devpts rw,seclabel,gid=5,mode=620,ptmxmode=000
20 18 0:17 / /dev/shm rw,relatime - tmpfs tmpfs rw,seclabel
21 1 253:0 / / rw,relatime - ext4 /dev/mapper/VolGroup-lv_root rw,seclabel,barrier=1,data=ordered
22 21 0:13 / /selinux rw,relatime - selinuxfs none rw
23 21 0:5 / /dev rw,relatime - devtmpfs udev rw,seclabel,size=755932k,nr_inodes=188983,mode=755
24 17 0:18 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,seclabel,mode=755
25 24 0:19 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
26 24 0:20 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuset
27 24 0:21 / /sys/fs/cgroup/ns rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,ns
28 24 0:22 / /sys/fs/cgroup/cpu rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpu
29 24 0:23 / /sys/fs/cgroup/cpuacct rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuacct
30 24 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,memory
31 24 0:25 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,devices
32 24 0:26 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
33 24 0:27 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_cls
34 24 0:28 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,blkio
35 17 0:29 / /sys/kernel/security rw,relatime - autofs systemd-1 rw,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5, direct
36 16 0:30 / /proc/sys/fs/binfmt_misc rw,relatime - autofs systemd-1 rw,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5, direct
37 18 0:31 / /dev/mqueue rw,relatime - autofs systemd-1 rw,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5, direct
38 17 0:32 / /sys/kernel/debug rw,relatime - autofs systemd-1 rw,fd=24,pgrp=1,timeout=300,minproto=5,maxproto=5, direct
39 16 0:14 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw
40 37 0:12 / /dev/mqueue rw,relatime - mqueue mqueue rw,seclabel
41 21 8:5 / /boot rw,relatime - ext4 /dev/sda5 rw,seclabel,barrier=1,data=ordered
42 36 0:33 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw
43 21 0:34 / /home/vas/.gvfs rw,nosuid,nodev,relatime - fuse.gvfs-fuse-daemon gvfs-fuse-daemon rw,user_id=500,group_id=500
44 17 0:35 / /sys/fs/fuse/connections rw,relatime - fusectl fusectl rw



It is not the same, and I want to know WHY and what for?

[dwightpaige79]

I just noticed that today's update included:


...
Installed:
upstart-sysvinit.x86_64 0:0.6.5-8.fc14
...
Replaced:
systemd-sysvinit.x86_64 0:10-1.fc14

Here's the full list on my box:

Dependencies Resolved

================================================== ================================================== ================================================== =
Package Arch Version Repository Size
================================================== ================================================== ================================================== =
Installing:
upstart-sysvinit x86_64 0.6.5-8.fc14 updates-testing 16 k
replacing systemd-sysvinit.x86_64 10-1.fc14
Updating:
audacious x86_64 2.4.0-3.fc14 updates-testing 359 k
audacious-libs x86_64 2.4.0-3.fc14 updates-testing 108 k
audacious-plugins x86_64 2.4.0-2.fc14 updates-testing 1.5 M
fedora-release-notes noarch 13.95.0-4.fc14 updates-testing 306 k
firstboot x86_64 1.113-2.fc14 updates-testing 175 k
ibus x86_64 1.3.7-5.fc14 updates-testing 368 k
ibus-gtk2 x86_64 1.3.7-5.fc14 updates-testing 26 k
ibus-gtk3 x86_64 1.3.7-5.fc14 updates-testing 25 k
ibus-libs x86_64 1.3.7-5.fc14 updates-testing 134 k
k3b-extras-freeworld x86_64 1:2.0.1-1.fc14 rpmfusion-free-rawhide 56 k
laughlin-backgrounds-gnome noarch 13.92.0-1.fc14 updates-testing 4.2 k
laughlin-backgrounds-kde noarch 13.92.0-1.fc14 updates-testing 7.6 k
laughlin-backgrounds-single noarch 13.92.0-1.fc14 updates-testing 6.7 M
libsmbclient x86_64 3.5.5-68.fc14 fedora 1.7 M
libuser x86_64 0.56.18-1.fc14 updates-testing 369 k
libuser-python x86_64 0.56.18-1.fc14 updates-testing 50 k
m17n-lib x86_64 1.6.1-5.fc14 updates-testing 169 k
mlocate x86_64 0.23.1-1.fc14 updates-testing 103 k
policycoreutils x86_64 2.0.83-28.fc14 updates-testing 676 k
policycoreutils-gui x86_64 2.0.83-28.fc14 updates-testing 206 k
policycoreutils-python x86_64 2.0.83-28.fc14 updates-testing 335 k
samba-client x86_64 3.5.5-68.fc14 fedora 11 M
samba-common x86_64 3.5.5-68.fc14 fedora 13 M
samba-winbind-clients x86_64 3.5.5-68.fc14 fedora 1.1 M
setroubleshoot x86_64 2.2.98-1.fc14 updates-testing 140 k
setroubleshoot-server x86_64 2.2.98-1.fc14 updates-testing 342 k
speech-dispatcher x86_64 0.7.1-1.fc14 updates-testing 340 k
system-setup-keyboard x86_64 0.8.6-2.fc14 updates-testing 14 k
systemd x86_64 10-2.fc14 fedora 441 k
systemd-units x86_64 10-2.fc14 fedora 114 k
traceroute x86_64 3:2.0.16-1.fc14 fedora 52 k
upstart x86_64 0.6.5-8.fc14 updates-testing 151 k
usermode x86_64 1.106.1-1.fc14 updates-testing 191 k
usermode-gtk x86_64 1.106.1-1.fc14 updates-testing 100 k
xdg-user-dirs x86_64 0.13-1.fc14 updates-testing 61 k
xorg-x11-drv-qxl x86_64 0.0.20.f14b-1.fc14 updates-testing 69 k
xorg-x11-server-Xorg x86_64 1.9.0-9.fc14 updates-testing 1.4 M
xorg-x11-server-common x86_64 1.9.0-9.fc14 updates-testing 72 k
yum noarch 3.2.28-4.fc14 updates-testing 917 k
Installing for dependencies:
libotf x86_64 0.9.11-1.fc14 fedora 83 k

Transaction Summary
================================================== ================================================== ================================================== =
Install 2 Package(s)
Upgrade 39 Package(s)


Seems as if something is afoot...

Wonder if this will fix the policykit crash on every reboot?

[Hansvon]

As you can see, FESCO has decided that upstart will be F14 init system. Read the devel and test mailing lists for more information.

[sonoran]

Irrespective of one's opinion of systemd, there really seem to be serious flaws in the fedora decision-making process. Just going by an innocent bystander's reading of the mailing lists, the process seems to result in making no one happy and quite a few unhappy.

A lot of people were apparently caught off guard by systemd's inclusion as the default in F14. Then, after a lot of work to find and fix issues to get systemd ready, it was suddenly dropped from F14. The minutes of the fesco meeting are, as they say, very interesting:
http://lists.fedoraproject.org/pipermail/devel/2010-September/142852.html

And Lennart Poettering's response:
http://lists.fedoraproject.org/pipermail/devel/2010-September/142858.html
There's something seriously wrong with the Fedora development process, folks. And with you, FESCO. You excelled in erratic behaviour, not in steering engineering.

As a fedora user, one doesn't know whether to laugh or cry. If the analogy one so often hears with regard to open source projects - "It's like herding cats" - applies, then I would have to say that right now the cats are winning.

[tox]

hmm doesnt look good from Lennarts post there, i dont care for systemd as i dont thinks its ready for inclusion as default in F14. the way Lennart spoke in that post almost sounded like he's ready to pack his bags an Develop for someone else, thats how pi$$ed he was

how many Developers have actually left Redhat this year? i know Jeremy katz has gone. 1 went to intel Alan Cox?

[sonoran]

It sounds like Lennart was putting in 20-hour days to get systemd ready, and if you read the mailing lists for the past several months he was really working hard to accommodate all the objections people had to systemd. Then at the last minute fedora reverses course and postpones systemd for 6 months. I think I'd be pissed too.

But there are also arguments on FESCO's side - do they want to run the risk of shipping a fedora 14 that simply won't boot on a lot of machines? That would be a PR nightmare.

Part of this is the longstanding fedora identity crisis. Is it cutting edge, designed for users who are capable of fixing problems, or is it a mass-appeal, ubuntu-like distro for users who just stick in a disc and get a working system? Obviously, trying to be both at the same time is not likely to succeed.

The possible reversion to upstart was planned for, and in that respect, you could say "the system worked". Looking for a possible bright side to all this, maybe the spotlight on fedora's organizational weaknesses will lead to a better process.

[nimnull22]

"It takes many good deeds to build a good reputation, and only one bad one to lose it."

Benjamin Franklin

And

"It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."

Warren Buffett

It will be Fedora 15, 16 17 .... There is plenty of time to make systemd the perfect system and session manager. Developers do not have to rush. Anyway it will be many new kernels, X11 servers. But Fedora has be always the same - the best, high reliable Linux OS. I really hope that FESCo makes decision from this point of view.

[sonoran]

All good points. But the time to take that cautious, conservative approach was right from the beginning. Why was systemd accepted as a "new feature" for fedora 14 to begin with? Presumably that was what Lennart had in mind when he pointed out FESCO's "erratic" behavior.

And the decision to adopt something as significant as a new init system should not have been allowed to surprise anyone. This should have been trumpeted everywhere, in BANNER HEADLINES, not left in meeting minutes and new feature lists that no one reads.

[nimnull22]

I think may be ...

It might be a good idea to make a "Systemd Spin", where everyone will have a chance to safely check what ever necessary and compare with default distribution.
Because systemd needs to be fully tested in real life.

[sonoran]

Someone mentioned that in the list - systemd should have been made a "New Technology Preview" for F14, so that users could turn it on and try it if they wanted to. That way it would receive wide testing and fedora would score some PR points for advancing the state of the art without breaking everything.

It's hard to fault anyone for this, Lennart naturally pushed to get his work released, and fedora's leaders, while wanting to be innovative, had to keep fedora's reputation in mind. But a 6-month release cycle is very fast, so taking 2 releases to convert to a new init system is not being overly conservative.

This is all very easy to judge in hindsight, of course.