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.
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. 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?) can I suggest you a workaround in the meanwhile ? set Storage=volatile in /etc/systemd/journald.conf. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org