Your message dated Thu, 07 Aug 2014 00:39:49 +0200
with message-id <[email protected]>
and subject line Re: Bug#755062: systemd: Syslog (contents that journalctl
shows) stopped working after upgrading from 204-14 to 208-6
has caused the Debian Bug report #755062,
regarding systemd: journalctl stopped working for unprivileged users (wrong
permissions) after upgrading from 204-14 to 208-6
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
755062: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755062
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 208-6
Severity: grave
Justification: causes data loss
Hi,
I upgraded from 204-14 to 208-6 last night and today in the morning, I
noticed that journalctl doesn't show any entries from after the
upgrade. Neither the at that time running "journalctl -f" nor a freshly
called journalctl show anything new. Just calling journalctl, it shows
all messages from boot up to when the upgrade happened.
There is no syslog daemon like e.g. rsyslog installed.
I have not yet rebooted, but I do expect that syslog must work after
upgrading systemd without having rebooted. Otherwise it would be a
severe data loss. And even if that would be the case: Either the running
"jpurnalctl -f" from 204 or the just called "journalctl" from 208 should
show something in this case.
If I can provide more information to investigate this issue, feel free
to ask. I'm though currently travelling (actually I noticed it because I
wanted to check for ppp messages in syslog) so I may lag a little bit
with regards to responses.
-- Package-specific info:
-- BEGIN ATTACHMENTS --
/tmp/tmp.R3QmnrfIV3/systemd-delta.txt
/tmp/tmp.R3QmnrfIV3/systemd-analyze-dump.txt
/tmp/tmp.R3QmnrfIV3/dsh-enabled.txt
-- END ATTACHMENTS --
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (110, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii acl 2.2.52-1
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-53.2
ii libacl1 2.2.52-1
ii libaudit1 1:2.3.7-1
ii libblkid1 2.20.1-5.8
ii libc6 2.19-7
ii libcap2 1:2.22-2
ii libcap2-bin 1:2.22-2
ii libcryptsetup4 2:1.6.4-4
ii libdbus-1-3 1.8.6-1
ii libgcrypt11 1.5.3-4
ii libkmod2 18-1
ii liblzma5 5.1.1alpha+20120614-2
ii libpam0g 1.1.8-3
ii libselinux1 2.3-1
ii libsystemd-daemon0 208-6
ii libsystemd-journal0 208-6
ii libsystemd-login0 208-6
ii libudev1 208-6
ii libwrap0 7.6.q-25
ii sysv-rc 2.88dsf-53.2
ii udev 208-6
ii util-linux 2.20.1-5.8
Versions of packages systemd recommends:
ii libpam-systemd 208-6
Versions of packages systemd suggests:
ii systemd-ui 3-2
-- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandleLidSwitch=suspend
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 208-7
Fixed by
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commit;h=71232687605f984ba22dd19fc9fa4b04024d9c52
which was included in the 208-7 release.
Michael
Am 18.07.2014 00:34, schrieb Axel Beckert:
> Control: severity -1 normal
> Control: retitle -1 systemd: journalctl stopped working for unprivileged
> users (wrong permissions) after upgrading from 204-14 to 208-6
>
> Hi Michael,
>
> Michael Biebl wrote:
>>> Michael Biebl wrote:
>>>> Do you use persistent logging (i.e. do you have a /var/log/journal
>>>> directory) or do you use volatile logging?
>>>
>>> AFAIK volatile logging. Otherwise I'd have an real syslog daemon
>>> installed. /var/log/journal does not exist.
>>>
>>>> What are the permissions of of the journal directory and the files
>>>> therein (either /var/log/journal or /run/log/journal)?
>>>
>>> $ ls -lR /run/log/journal
>>> /run/log/journal:
>>> total 0
>>> drwxr-xr-x 2 root root 140 Jul 17 04:49 492db8f3b777b11e00f22f1853442bf7/
>>>
>>> /run/log/journal/492db8f3b777b11e00f22f1853442bf7:
>>> total 69404
>>> -rw-r----- 1 root root 8388608 Jul 17 23:32 system.journal
>>> -rw-r----- 1 root systemd-journal 14618624 Jul 1 13:24
>>> system@00f9271567a145869260b64961e15f3f-0000000000000001-0004fc8358668c0b.journal
>>> -rw-r----- 1 root systemd-journal 16502784 Jul 5 02:01
>>> system@00f9271567a145869260b64961e15f3f-0000000000004a8c-0004fd2003dd7bb2.journal
>>> -rw-r----- 1 root systemd-journal 14782464 Jul 10 13:54
>>> system@00f9271567a145869260b64961e15f3f-000000000000a0ff-0004fd66f2b4c138.journal
>>> -rw-r----- 1 root systemd-journal 16777216 Jul 17 04:48
>>> system@00f9271567a145869260b64961e15f3f-000000000000f40d-0004fdd57c902758.journal
>>
>> That system.journal is root:root owned is a bit strange. Are you running
>> journalctl as root or (unprivileged) user?
>
> As unprivileged user.
>
>> Apparently this file is still changed, looking at the date "Jul 17 23:32
>> system.journal".
>
> Indeed. And "journalctl -f" works fine as root. No idea why these
> permissions changed with the upgrade.
>
>> If you run "sudo journalctl -f" and logger foo, do you see this message
>> show up in the journal or not?
>
> Well, not using sudo (why does everybody insist on using sudo even
> though it's not even installed by default?), but executing journalctl
> as root, journalctl yields the expected data.
>
> I'm hence lowering the severity further as the data is obviously not
> lost. Also retitling according to the findings.
>
>> Is this maybe a VM where you could snapshot the current state
>
> No, it's a laptop with root on an LV on an encrypted VG/PV on SSD.
> (Which is the reason why I only want volatile logs there.
>
>> to check if a reboot does fix the issue?
>
> Will check anyway. Since we now know what made the user no more being
> able to access the log, the only issue left is finding the cause for
> the permission change.
>
>> Btw., I'll be away for the next couple of days. I hope someone else from
>> the team can further assist with debugging this issue.
>
> No more hurry from my side as the issue is clearly less severe than I
> feared. Thanks for the assistance so far!
>
> Regards, Axel
>
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
