[EN] Survey on systemd Who uses it?

[GoinEasy9]

To all those using systemd: Something interesting just appeared on the fedora-devel mailing list.  A corruption problem with systemd-journal and btrfs.  I still haven't experimented with btrfs, so, I'm at a loss as to some of the nomenclature.  The bugzilla link is interesting also.
 
https://lists.fedoraproject.org/pipermail/devel/2013-September/189610.html

[devil]

you could also have a look at fedora 20 alpha at http://fedoraproject.org/get-prerelease. It comes without syslog and with systemd journal.

greetz
devil

[GoinEasy9]

I have fedora 20 installed on one hard disk, but haven't really done anything but update it since its install.  I keep it to reference newer changes to systemd, but, it seems fedora 19 is keeping up with systemd versions, so, my main F19 install is sufficient.  I used to use it to keep an eye on KDE, but, it seems siduction is doing a better job with that.

BTW - Running f20 without syslog isn't as much fun as reading the discussions that lead up to it.

https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html

I like systemd-journal.  I just have to use it more to get used to it.  Using Krusader Root-mode and visiting /var/log is just second nature to me.

As far as the journal/btrfs corruption bug?  It's just par for the course.  I remember an ext4 data corruption bug that was found and fixed just before ext4 became default.  Mixing a new init system with a new feature filled file system is bound to create a few hiccups.

[dibl]

Thanks GoinEasy9.  I have no need to rebalance my 2-drive BTRFS filesystem, which seems to be doing fine, holding only my data.  It looks like the issue may be limited to the case where the OS is on BTRFS -- I can't quite tell.  Thanks for posting this -- it is worth keeping an eye on.

[GoinEasy9]

@dibl - I thought of you when I read the post, that's why I posted it.  I figured if anyone would encounter this bug it would be you.  At least you would be the one to understand what they were talking about.

When our next release iso's are available, I'm going to try a btrfs install myself.  Thanks for breaking it in for me. :lol:

[dibl]

As far as I can tell from the BTRFS wiki, rebalancing (re-striping the RAID) is only needed when you add or remove a block device to/from a multi-device filesystem.  This would be important if you were managing a server full of hard drives and swapping in new drives or removing old drives.  If that is true, then the procedure used by the bug reporter does not make sense -- there is no reason to rebalance a single filesystem such as / or /home.  However, the command should not cause anything to break, so the bug is technically valid.

I made my BTRFS filesystem across two drives in the first place, and have never added nor removed a drive, so rebalancing has never been needed in my case.

[timc]

I have rebalanced before. When I had a fiasco with systemd/udev and ended up reinstalling Siduction from scratch, I made a mistake and my btrfs filesystem was created as RAID-1 instead of RAID-0. So I converted it to RAID-0 and rebalanced it so the striping would be uniform.

Also, the guy who reported the bug is probably an "official" tester who goes through all types of operations just to make sure they work. That is just my guess, though.

Tim

[dibl]

The upgrade of acpid to ver. 2.0.20-1 seems to be a bit problematical for systemd. On several (or all) of my half-dozen systems, I saw a hang of the ugprade at the point where the running acpid service was supposed to be shut down. On all but one system, I was able to resolve it with "dpkg --configure -a".  On my Toshiba netbook, I could finish d-u, but the prior package would never be removed, so every d-u pulled in the new version, and then hung up trying to shut off the running service.  "apt-get purge" could not remove it, either.  This morning I fixed it by taking systemd-sysv off hold, letting sysvinit be installed, rebooting, and running the d-u in init 3.  Then I reinstalled systemd-sysv and it's all OK.

This is just FYI if anyone else has the same problem with acpid.


EDIT 29 SEP:  To clarify, this fix was necessary on both of my 32-bit installations and none of my 64-bit installations.

[ReinerS]

After new installation I am experimenting with systemd again. Looks promising yet.

However I found that the "at" package is now not installable as it seems to insists on the "real" cron, not the service provided by systemd.

As I need to run specific tasks not regulary but at specified times (i.e. halt the system at 4:00) I would need this service.

There was as "systemd atd.service" mentioned at some loccations but this service seems to be not available yet.

Is there any other solution or a workaround available ?

regards

Reiner

[devil]

you could ask in #debian-systemd on oftc.

greetz
devil

[ReinerS]

Well might not actually been caused by systemd but since I changed to systemd I experience quite a lot system- / x-freezes and even more unclean file-systems on startup which cause quite some work with fscks.

Can also be kernel or xorg (or a mixture of all) related, as there had been some upgrades to those, but I think I experienced those since the newinstallation with the change to systemd some days ago.
The home directory (partition) pretty often now suddenly out of the blue is mounted ro and programs cannot write into their configs and folders and store data down.

Had no similar trouble before. The filesystems on this box are ext4.

regards

Reiner

Edit:
In the syslog I currently found huge amounts of those messagges:

Code: [Select]

Oct 22 20:12:39 TowerLX kernel: [16314.797846] retire_capture_urb: 33 callbacks suppressed
Oct 22 20:12:45 TowerLX kernel: [16320.793338] retire_capture_urb: 41 callbacks suppressed
Oct 22 20:12:51 TowerLX kernel: [16326.930413] retire_capture_urb: 24 callbacks suppressed


[dibl]

Googling is telling me that your error is related to some USB sound device, for example:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=15851

I don't see anything about systemd and that kernel message.

I am using ext4 filesystems, as well as one btrfs filesystem, and I have not seen any unusual fsck activity since converting multiple computers to systemd.

[ReinerS]

Hmm, I 'll look into that.

I have a webcam with integrated micro connected via usb only.
Maybe this coudl casus that.

regards

Reiner

[ReinerS]

Well,
after removing that webcam (with integrated micro, handled viausb too) those mass messages had gone and I found only messages from nouveau on both (in the meantime  I had a similar machine portesd to systemd) systems. And the freezes went on.

Additionly I found now quite an amount of bad-blocks on my main-box.  :'(

So I reinstalled my mainbox completely (no badblocks at all now), removed nouveau and installed the nvidia pro. driver and changed to systemd again. Until now no more freezes. Hope it stays in that way

One thing I found is that systemd not alway copes well yet with boot-splash programs like plymouth. On one box (same mainboard) it works pretty well, but on my main-box I deaktivated it by removing "splash"from the grub command-line.

regards

Reiner

[dibl]

I have 1 system using the nouveau driver, and 3 using the nvidia proprietary driver, all booting with systemd, and all working good.  (Until one of the 3 blew its LCD panel the other day ...    ).