Hi Michael,
nice to read you again. Quite some time has passed. About a year ago I
was so fed up with this NAS and these bugs that I sold it. I built my
own server running debian again and since then I had no issues at all.
Rock solid. I suggest to close this bug for now until somebody reopens
it.
Control: tags -1 + moreinfo
Hi Tino,
I'm looking through old bug reports.
A lot has changed since v215, so it would be great if you can test this
with v232 from current stable or event better v235 from testing and
report back, if the issue is still reproducible.
Regards,
Michael
--
Why is it th
Maybe i found another hint:
$ ps aux | grep defunct
draghi5416 0.0 0.3 4224 1968 pts/0S+ 12:08 0:00 grep
defunct
$ sudo poweroff
Failed to start poweroff.target: Connection reset by peer
Failed to open initctl FIFO: No such device or address
Failed to talk to init daemon.
$ sudo p
Hi Michael, nice to read you! :)
Yes I indeed do. And I was almost about to build a new selfmade NAS some
days ago just to get rid of the regular annoyance of rebooting.
Back in August 2015 I was using the formerly up to date systemd of
Stretch (221-1) on my Jessie system. With this version, syst
Hi Tino
On Sat, 22 Aug 2015 13:13:20 +0200 Tino wrote:
> Hi everyone,
>
> it has been one month since the last crash. I wanted to check if
> everything is ok today and right in to moment i tried to access systemd,
> it crashed. Unfortunately, it received an ABRT signal right after the
> SEGV, wh
Hi everyone,
it has been one month since the last crash. I wanted to check if
everything is ok today and right in to moment i tried to access systemd,
it crashed. Unfortunately, it received an ABRT signal right after the
SEGV, which had overwritten the core dump. So i couldn't figure out
where the
Ths system was running for two weeks now with no issues. I almost
gathered some hope, that it's finally stable now. :( Next crash..
This time sshd crashed in the first place and the stack of the coredump
seems broken. Both very strange, that never happened before.
As usual, all other services remai
Hello Tino,
Tino [2015-07-06 20:11 +0200]:
> root 4060 0.0 0.2 1772 1124 ?S19:21
> 0:00 \_ /bin/sh /usr/sbin/invoke-rc.d smbd reload
> root 4079 0.0 0.4 4424 2556 ?S19:21
> 0:00 \_ systemctl reload smbd.service
>
Am 05.07.2015 um 14:32 schrieb Michael Biebl:
> Sorry for the inconvenience.
>
> I think the best course of action would be, if you could install systemd
> v221 from testing, and if the problem is still reproducible there, we
> take this upstream.
>
> Would you be willing to do that?
I upgraded sy
Am 05.07.2015 um 14:16 schrieb Tino:
> Another systemd segfault.
> I still didn't find a workaround for this problem and the reboots every
> few days is getting quite annoying. :/ At least it looks like i am the
> only one with this problem.
Sorry for the inconvenience.
I think the best course of
Another systemd segfault.
I still didn't find a workaround for this problem and the reboots every
few days is getting quite annoying. :/ At least it looks like i am the
only one with this problem.
Jul 02 06:32:05 Storage-Blue systemd[1]: Got message type=signal
sender=org.freedesktop.DBus destinat
The next SEGV. Looks like this time it crashed while rotating the log. I
was not around. I also found a zombie killall, but i couldn't find a
hint where it was comming from. Maybe the logrotate script?
Jul 01 06:34:28 Storage-Blue systemd[1]: Got message type=signal
sender=org.freedesktop.DBus des
Another crash. This time while doing an apt upgrade. I seems not related
to adding new jobs or the hashmap iteration. I have no idea where this
signal is coming from. There is nothing but the usual watchdog messages
in the log before the SEGV.
Jun 30 12:02:08 Storage-Blue systemd[1]: systemd-journa
It took quite a long this time. The system was running over a week. I
got a log of the crash and all other services were running normal
(except for sshd and systemd of course) for another ~30h until i
rebootet it. I looks like sshd crashed first and systemd followed while
adding a restart job. debs
Hi Martin
Am 02.06.2015 um 05:44 schrieb Martin Pitt:
> Control: fixed -1 219-1
> Control: severity -1 important
>
> Hello Tino,
>
> Tino [2015-06-01 23:13 +0200]:
>> This time it segfaulted while adding a job that should restart journald.
>
> This is known to not work. Don't restart journald f
Control: fixed -1 219-1
Control: severity -1 important
Hello Tino,
Tino [2015-06-01 23:13 +0200]:
> This time it segfaulted while adding a job that should restart journald.
This is known to not work. Don't restart journald for 215, as it has
no way to save its open pipes from connected services
Am 01.06.2015 um 23:56 schrieb Tino:
> I don't know why or when this job was triggered. The uptime of the
> system was about 1.5-2 days until it happened.
> I don't have any custom or modified units. The only change i made with
> systemd is setting the log level to debug.
> I've seen a sefault whil
I don't know why or when this job was triggered. The uptime of the
system was about 1.5-2 days until it happened.
I don't have any custom or modified units. The only change i made with
systemd is setting the log level to debug.
I've seen a sefault while systemd was processing systemd-udevd events
t
Am 01.06.2015 um 23:13 schrieb Tino:
> Package: systemd
> Version: 215-17
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> systemd doesn't survive two days on my bare minimal headless NAS
> installation. I already purged all unused packages, reinstalled syste
Package: systemd
Version: 215-17
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
systemd doesn't survive two days on my bare minimal headless NAS
installation. I already purged all unused packages, reinstalled systemd
and reverted all config files to factory default, re
20 matches
Mail list logo
