Am 14.04.2013 02:15, schrieb Cristian Rodríguez:
El 13/04/13 20:34, Stefan Seyfried escribió:
That's not feasible as I need to enable
debugging at boot and then have
lots debug information wasting cycles just to debug the shutdown 2 weeks
later once a new kernel is out.
Or is there a way to enable debugging just before shutdown? I have not
didnt this --> http://freedesktop.org/wiki/Software/systemd/Debugging
Cite: "after booting with systemd.log_level=debug
I'm not very inclined towards running all productive systems with "sir
spamalot" configuration to diagnose eventual shutdown problems.
I'll probably look into the debug shell.
Anyway -- debugging this with SysV init was a breeze compared with systemd.
are you sure the "freeze" is caused by
systemd ? maybe be kernel
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.
does not mount every second boot. This time it was
actually asking me for the password on the text console and echoing the
passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times
in bugzilla, but I'm just tired of it.
There were bugs, in the next iteration of systemd there are fixes
included for that.
Yes, there have always been, in every iteration since I first tried
systemd-30 or such. However, with SysV init my very same cryptohome has
just worked for way longer than 10 years.
10 years from now, maybe it will even work with systemd.
syslog-ng does not work. Only "Forwarding to syslog missed
XXX messages" all the time.
have you considered that might be a bug in syslog-ng units and nothing
to do with systemd ?
Syslog worked very well before systemd / journal got forced down
One thing I really hate about systemd is the total ignorance of both
upstream and many of its downstream proponents (Frederic is explicitly
excluded from this rant):
"we break everything *simply because we can*"
"everybody else needs to clean up the mess we left"
The tipping point for me was the "break everybody's suspend keys
config". Now I'm done with it.
Syslog worked before systemd.
Then it broke (until yesterday, right now it seems to work but that
might be typical nondeterministic systemd behaviour). IMNSVHO the ones
who broke it should fix it. No, the finger is pointed at everybody else
doing "broken" things -- funnily the same "broken" things have worked
for ages before.
(and no, journal is not an
alternative, because the performance is abysmal.
hitting "end" thrashes my disk for about three minutes before
responding. I can grep through 3 Years worth of /var/log/messages-* in
the same time).
Since systemd 195 there have been a lot of improvements into the
journal, I suggest you test and report what happends with systemd > 201
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
Maybe it works
for you, but for me it is an nondeterministic heap of
crap. Latest example: Curiously after timedatectl was mentioned in this
hread, I issued "timedatectl" as a nonprivileged user(!) to see what it
would give me. Now I no longer can start / stop ntp and ntp is broken.
WTF? (Yes, I killed all involved processes I could find in the mean
time). Probably the solution will be a reboot. Systemd really brings us
closer to the other "great" Desktop OS's.
timedatectl does not cause any misbehaviour here and well, NTPD is not
integrated with timedatectl/timedated in 12.3
I'm running Factory, there it is even more broken apparently.
(Yes, I know, Factory might contain new bugs, this is why I normally
keep silent about all the systemd stuff. I joust could not stand the
cheering systemd crowd anymore this time. I'll go back and just work
around the issues for me now. Building a full featured current busybox
.. it does not have native
units and does not have hooks into it, this is not a bug of systemd but
on the ntp package.
Yeah, but why do the systemd proponents not fix it? Why does everyone
need to clean up after systemd?
"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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org