On Thu, 6 Aug 2015 at 21:29 Michael Biebl wrote:
> Is another process blocking suspend?
> What's the output of systemd-inhibit?
>
prune# systemd-inhibit
Who: NetworkManager (UID 0/root, PID 535/NetworkManager)
What: sleep
Why: NetworkManager needs to turn off networks
Mode: de
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package systemd
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.o
#
# bts-link upstream status pull for source package systemd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #788269 (http://bugs.debian.org/788269)
# Bug title: machinectl loses track of running
- Forwarded message from q...@9398.at -
Date: Thu, 6 Aug 2015 18:03:43 +0200
From: q...@9398.at
To: Michael Biebl
Subject: Re: Bug#794755: systemd kills ssh-server
User-Agent: Mutt/1.5.23 (2014-03-12)
On Thu, Aug 06, 2015 at 04:10:28PM +0200, Michael Biebl wrote:
> [please always CC the
On Thu, 2015-08-06 at 16:57 +0200, Michael Biebl wrote:
> Looks like this should be fixed in binutils for good instead of
> having individual packages work around that.
They are active changing the sources in git the past months. Searching
for Sparc. Question, Is the bug stil there?
https://sou
Am 06.08.2015 um 16:13 schrieb d...@mattli.us:
> Richard Mortimer writes:
>
>> So maybe the code is trying to use the wrong string as input to chdir
>> and hence failing.
>
> Is udev using the gold linker during build?
It is, indeed.
We had a hack in debian/rules for a while, to use ld.bfd on
Richard Mortimer writes:
> So maybe the code is trying to use the wrong string as input to chdir
> and hence failing.
Is udev using the gold linker during build? I've been looking into a bug
where in certain circumstances, when linking with gold, string literal
function arguments are corrupted.
У Вас 1 новое сообщение
От кого: Янита
Тема: Забери свою 1000$
Сообщение: Новое предложение от старого бренда. Вулкан ставки на спорт -
рискуй, играй и побеждай! Поставь на любимого бойца! А также, получи бонус до
1000$ при пополнении своего депозита, а главное, не тяни с этим..
Заработать на
У Вас 1 новое сообщение
От кого: Марина
Тема: Забери свою 1000$
Сообщение: Умеете играть в покер? Тогда получите 1000$ на первый депозит, и
станьте победителем турнира с отдельным призом!
Играть сейчас
, Вы можете ограничить или отменить уведомления на E-Mail в Настройках
оповещений
__
[please always CC the bug report]
Am 06.08.2015 um 14:58 schrieb q...@vienna.at:
> On Thu, Aug 06, 2015 at 01:25:59PM +0200, Michael Biebl wrote:
>> It looks like ssh service is restarted too often within a short period
>
> Perfectly true.
>
>> of time due to some external process (most likely t
On 06/08/2015 12:48, Artyom Tarasenko wrote:
> Here is the correspondinf part of the gdb session with symbols from
> systemd-dbg_224-1_sparc64.deb:
>
Many thanks.
The log below pretty much does confirm that it is taking the suspected
path through the code. Some steps are not visible to the debug
And here is an attempt to debug why parse_proc_cmdline fails:
Breakpoint 3, main (argc=, argv=0x7fefc98) at
../src/udev/udevd.c:1662
1662r = parse_proc_cmdline(parse_proc_cmdline_item);
(gdb) step
parse_proc_cmdline (parse_item=0x1011180
) at ../src/basic/util.c:4832
4832
Here is the correspondinf part of the gdb session with symbols from
systemd-dbg_224-1_sparc64.deb:
(gdb) run
Starting program: /lib/systemd/systemd-udevd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Breakpoint 3, main (
Am 06.08.2015 um 12:07 schrieb Brian May:
> On Thu, 6 Aug 2015 at 19:56 Brian May wrote:
>
>> Then again, maybe I was premature; I think I should do a reboot and redo
>> the following:
>>
>
> Really good theory, however after a reboot everything is fine:
>
> [brian:~] % for i in /sys/class/drm/
Am 06.08.2015 um 12:28 schrieb Thomas Schmidt:
ug 06 10:43:50 9398 systemd[1]: ssh.service: Main process exited,
code=exited, status=255/n/a
> Aug 06 10:43:50 9398 systemd[1]: ssh.service: Unit entered failed state.
> Aug 06 10:43:50 9398 systemd[1]: ssh.service: Failed with result 'exit-code'.
> A
It looks like stdout and/or stderr output is mixed up with the strace
output but it looks udevd is failing because the chdir to / fails.
Notes inline below. (Caution I'm comparing against current systemd git
HEAD and not any specific version)
http://cgit.freedesktop.org/systemd/systemd/tree/src/u
On Thu, 6 Aug 2015 at 19:56 Brian May wrote:
> Then again, maybe I was premature; I think I should do a reboot and redo
> the following:
>
Really good theory, however after a reboot everything is fine:
[brian:~] % for i in /sys/class/drm/*/*/status ; do echo $i ; done
/sys/class/drm/card0/card0
On Thu, 6 Aug 2015 at 18:31 Michael Biebl wrote:
> Do you use an external monitor? If logind detects an external monitor,
> it suppresses any suspend requests.
>
Yes, I saw that code. There should be no reason for it to detect in
external monitor, however that doesn't mean it isn't getting it wr
That's what I see in the strace log:
set_tid_address(0xf80100133790) = 9184
set_robust_list(0xf801001337a0, 24) = 0
rt_sigaction(SIGRTMIN, {0xf801006c6da0, [], SA_SIGINFO}, NULL,
0xf801006d2098, 8) = 0
rt_sigaction(SIGRT_1, {0xf801006c6c40, [], SA_RESTART|SA_SIGINFO},
NULL
Hi Brian,
Am 06.08.2015 um 10:17 schrieb Brian May:
> When closing the lid, system doesn't suspend, all I get is the following
> logged in auth.log:
>
> Aug 6 15:20:36 prune systemd-logind[571]: Lid closed.
> Aug 6 15:20:47 prune systemd-logind[571]: Lid opened.
>
> Occassionally the system do
Processing commands for cont...@bugs.debian.org:
> severity 794744 normal
Bug #794744 [systemd] systemd-logind: Lid closed event does not suspend
Severity set to 'normal' from 'important'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
794744: http://bugs.debian.o
21 matches
Mail list logo
