(maybe we should move the discussion to factory? anyway, I'd think we better let it die soon) Am 14.04.2013 19:18, schrieb Cristian Rodríguez:
El 14/04/13 06:09, Stefan Seyfried escribió:
Anyway -- debugging this with SysV init was a breeze compared with systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging shell scripts.
Which is a breeze compared with debugging systemd. As systemd is PID 1, a single mistyped debug-printf in the code will panic my system. If I mistype something in an init script, I boot with init=/bin/bash and fix the typo. Compared to "#!/bin/bash -x" in the old-style init scripts, it is much harder to debug systemd correctly.
Pretty sure. After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting, more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of the time. Does not really look like a kernel problem to me.
If your machine has /dev/watchdog device you could also set RuntimeWatchdogSec=20s in /etc/systemd/system then the hardware will take care of rebooting the machine when things go bad.
Actually I'd prefer to do sysrq-E, syrq-I, sysrq-S, sysrq-U before just rebooting it hard. Often enough, a few additional sysrq-E and ctrl-alt-del actally make sytemd reboot the system, but it takes way longer than the old "slow" sysV init... so much for fast booting, fast shutdown surely comes with the next version.
However it will be cool to know why does it "freeze" at boot.
One thing I really hate about systemd is the total ignorance of both upstream.
Then you are not paying good attention, pretty much everything has or is landing in upstream projects in one way or another.
I doubt they will fix the online file format after the fact. The problem is, that it creates massively fragmented files on-disk and this hurts everyone with non-SSD setup. Probably it works well on Lennart and Kay's notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10 seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for too long.
Since I see you are using syslog..(and by your description of fact, the journal lives on a btrfs partition..does it?)
No. plain old ext4. I'm a bit conservative on my production machines.
can I suggest you a workaround in the meanwhile ? set Storage=volatile in /etc/systemd/journald.conf.
I'll do that once I gained some confidence that the working syslog is not an accident (means: it survives a few reboots). Again with the journal, similar to systemd: the idea looks promising, but the implementation is painful. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org