Re: [systemd-devel] Failed to get journal fields: Bad message

[Krzysztof Błaszkowski]

On Sun, 2017-02-26 at 21:45 +0100, Lennart Poettering wrote:
> On Sat, 25.02.17 11:10, Krzysztof Błaszkowski (k...@sysmikro.com.pl)
> wrote:
> 
> > 
> > 
> > Any thoughts ? wise only ..
> > 
> > when there was /var/log/messages available there was no problem
> > with
> > accessing logs because the "database" was plain text but now.
> > 
> > corrupted less or more it did not matter. it is responsibility of
> > /var/log filesystem to perform right recovery ..
> > 
> > I want to see what could happen before I had to hard reboot and I
> > can't
> > access "messages" even before a month ago.
> > 
> > 
> > don't want to see reply like this:
> > http://forums.fedoraforum.org/showthread.php?t=311314
> > 
> > because I will express how stupid *-journal idea is.
> > and making double recovery scheme by the file system and poor one
> > by *-
> > journal is so brain fucked like I have never seen yet.
> 
> The journal file format is primarily an append-based format (though
> some fields at the front are updated, to link the new additions
> up). This makes it not too bad when it comes to disk corruptions, and
> data up to the point of corruption should be readable pretty nicely
> still.
> 
> 

well, the most interesting information is located beyond that point
very often. 


> Anyway, if you have a corrupted journal file and current journalctl
> can't read it, then please file a bug, attach the journal file, and
> we'll look into improving journalctl.
> 

journalctl --verify
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-
1105.journal 
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005495e
2bb26863-aa72c6a8a7437123.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005455b
e5e6181f-8616123458bd2b50.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@00054956
b0c61ef7-6f0ef8bfd59ad5e8.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@00054
95e2c558675-4af46c2d79464765.journal~
549f50: Invalid entry item (7/9 offset:
00
549f50: Invalid object contents: Bad
message  
File corruption detected at /var/log/journal/52f04da61fa8108cd5f48bca58
6164a2/system@0005495abfa1c9d8-cf2df0a23044.journal~:549f50 (of
8388608 bytes, 66%).
FAIL: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005495a
bfa1c9d8-cf2df0a23044.journal~ (Bad message)
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@00054
55bfdbeb23d-1ff3046498e945ad.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005495e
3d56c587-44f1967167aac5a3.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@65bee6e3
4f3c4b77b265431a1dd2a6df-0001-0005459b8fd2a11e.journal
c84f48: Invalid entry item (8/24 offset:
00   
c84f48: Invalid object contents: Bad
message  
File corruption detected at /var/log/journal/52f04da61fa8108cd5f48bca58
6164a2/system@0005459b8ff5e32b-620437abf7009d7d.journal~:c84f48 (of
16777216 bytes, 78%).
FAIL: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005459b
8ff5e32b-620437abf7009d7d.journal~ (Bad message)
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-
1000.journal 
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@00054
95e3de63208-bbc6d86046b94014.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1105@2a1f1
b3f5241431483971743eded852c-d6d6-000547f91700222b.journal
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@00054
59b907b630d-a25c081908a032be.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005495e
8db292fb-cb1d4cbe87b5093f.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1001@1dd4c
9dcd66446b483e91ea564f6f1b6-43c6-0005478f1ea62cb4.journal
PASS:
/var/log/journal/52f04da61fa8108cd5f48bca586164a2/system.journal   
 
3a86e0: Invalid
object 
   
File corruption detected at /var/log/journal/52f04da61fa8108cd5f48bca58
6164a2/user-1000@0005495ac03d6f02-bc5bf9a6b1d16fec.journal~:3a86e0 (of
8388608 bytes, 45%).
FAIL: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@00054
95ac03d6f02-bc5bf9a6b1d16fec.journal~ (Bad message)
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005455b
eea9f506-e4b5738d99c3f3ab.journal~
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-
1020.journal 
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-
1005.journal 
PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@8d932
e8a67a74b8483761b6d509bd81f-05e0-0005459b907b791b.journal
PASS: 

Re: [systemd-devel] How to have systemd --user instance share the same environment variables as the X server?

[Mantas Mikulėnas]

On Sun, Feb 26, 2017 at 11:10 PM, Patrick Schleizer <
patrick-mailingli...@whonix.org> wrote:

> Being on Debian stretch (Qubes). The display manager there does not yet
> get started by systemd --user.
>
> I find it useful to convert /etc/xdg/autostart/app.desktop files to
> systemd --user unit files.
>
> Therefore the environment variables have to be sorted out. On any Linux
> we would have to set at least DISPLAY as well as XAUTHORITY.
>
> On Qubes however, we need a few more environment variables. We need also
> QT_X11_NO_MITSHM=1 and may need a few others ones.
>
> Now, before I go through them manually and then have this break in
> future when more/different environment variables are needed...
>
> Is there a way to have the systemd --user session share the same
> variables as the X server? Writing a parser for /etc/X11/Xsession.d/
> seems wrong. Am I missing some tool to do that?
>
> Would I add something like this?
>
> ExecStartPre=dbus-update-activation-environment --systemd --all
>

Those don't sound like X server variables – they're X *client* variables,
aren't they?

If you're in charge of the distro, and if the variables are fairly static,
a) set them via the pam_env PAM module (i.e. /etc/environment),
or b) set them with Environment= in "user@.service".

That said, in many distributions Xsession already calls
`dbus-update-activation-environment…` right after having sourced all the
Xsession.d scripts.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udev rules: add udev rule to create /dev/ptp_kvm

[Lennart Poettering]

On Thu, 23.02.17 22:20, Marcelo Tosatti (mtosa...@redhat.com) wrote:

> 
> Its necessary to specify the KVM PTP device name in userspace.
> 
> In case a network card with PTP device is assigned to the guest,
> it might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1. 
> 
> Fix a device name for the KVM PTP device.

What's the symlink precisely good for, can you elaborate? 

Also, what's the benefit of shipping this upstream? Why not ship that
rule with kvm?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can a systemd --user instance rely on After= of systemd --system instance?

[Lennart Poettering]

On Sat, 25.02.17 17:34, Patrick Schleizer (patrick-mailingli...@whonix.org) 
wrote:

> Hi,
> 
> I read, that a systemd --user instance cannot use Requires=.
> 
> But what about After=? Can a systemd --user instance use
> After=some-system.service?

The units of the --user instance live in an entirely disjunct
namespace from those in the --system instance. Hence yes, you can
absolutely use After= and/or Requires= between two user services, but
it will always just be between two *user* services, and never between
a user and a system service, since the unit state engines of the
system and user instance are completely disconnected, as said.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Failed to get journal fields: Bad message

[Lennart Poettering]

On Sat, 25.02.17 11:10, Krzysztof Błaszkowski (k...@sysmikro.com.pl) wrote:

> 
> Any thoughts ? wise only ..
> 
> when there was /var/log/messages available there was no problem with
> accessing logs because the "database" was plain text but now.
> 
> corrupted less or more it did not matter. it is responsibility of
> /var/log filesystem to perform right recovery ..
> 
> I want to see what could happen before I had to hard reboot and I can't
> access "messages" even before a month ago.
> 
> 
> don't want to see reply like this:
> http://forums.fedoraforum.org/showthread.php?t=311314
> 
> because I will express how stupid *-journal idea is.
> and making double recovery scheme by the file system and poor one by *-
> journal is so brain fucked like I have never seen yet.

The journal file format is primarily an append-based format (though
some fields at the front are updated, to link the new additions
up). This makes it not too bad when it comes to disk corruptions, and
data up to the point of corruption should be readable pretty nicely
still.

Anyway, if you have a corrupted journal file and current journalctl
can't read it, then please file a bug, attach the journal file, and
we'll look into improving journalctl.

If you think that our ideas, and in particular journal files are
stupid, then please use something else, there are plenty syslog
implementations around, and they still work on systemd.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to have systemd --user instance share the same environment variables as the X server?

[Patrick Schleizer]

Being on Debian stretch (Qubes). The display manager there does not yet
get started by systemd --user.

I find it useful to convert /etc/xdg/autostart/app.desktop files to
systemd --user unit files.

Therefore the environment variables have to be sorted out. On any Linux
we would have to set at least DISPLAY as well as XAUTHORITY.

On Qubes however, we need a few more environment variables. We need also
QT_X11_NO_MITSHM=1 and may need a few others ones.

Now, before I go through them manually and then have this break in
future when more/different environment variables are needed...

Is there a way to have the systemd --user session share the same
variables as the X server? Writing a parser for /etc/X11/Xsession.d/
seems wrong. Am I missing some tool to do that?

Would I add something like this?

ExecStartPre=dbus-update-activation-environment --systemd --all

Best regards,
Patrick

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel