Re: [systemd-devel] ip_forward issue again
Am 17.08.2015 um 22:51 schrieb Johannes Ernst: The strange "sysctl fails to setup IP forwarding #468”, closed after ordering systemd-sysctl and systemd-networkd, unfortunately still occurs for me. https://github.com/systemd/systemd/issues/468#issuecomment-117904714 since the timing was repeatly unpredictable i added the service below on every machine years ago to re-execute sysctl *after* al network stuff was started [root@srv-rhsoft:~]$ cat /etc/systemd/system/sysctl-post-network.service [Unit] Description=apply settings after network After=network.service systemd-networkd.service network-online.target openvpn.service hostapd.service network-wlan-bridge.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/sysctl -p StandardOutput=null [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ip_forward issue again
The strange "sysctl fails to setup IP forwarding #468”, closed after ordering systemd-sysctl and systemd-networkd, unfortunately still occurs for me. https://github.com/systemd/systemd/issues/468#issuecomment-117904714 Cheers, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: filter and search journalctl
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Anne Mulhern" > Cc: systemd-devel@lists.freedesktop.org, "Sebastian Schindler" > > Sent: Monday, August 17, 2015 10:45:11 AM > Subject: Re: [systemd-devel] RFC: filter and search journalctl > > On Mon, Aug 17, 2015 at 10:24:22AM -0400, Anne Mulhern wrote: > > > > > > > > > > - Original Message - > > > From: "Zbigniew Jędrzejewski-Szmek" > > > To: "Sebastian Schindler" > > > Cc: systemd-devel@lists.freedesktop.org > > > Sent: Saturday, August 8, 2015 3:48:30 PM > > > Subject: Re: [systemd-devel] RFC: filter and search journalctl > > > > > > On Fri, Aug 07, 2015 at 11:53:13AM +0200, Sebastian Schindler wrote: > > > > Grep-ing seems to be the only solution to find log entries if you don't > > > > fully > > > > know what you're looking for. For example: You want to see all entries > > > > containing a certain MESSAGE that gets enriched with additional > > > > information > > > > during the logging process: > > > > > > > > MESSAGE=host has closed connection > > > This is a bit contentious, but at least I would like to see some > > > grep functionality implemented directly in journalctl. > > > > > > > I am late to the party, but I think it is obvious that the "right" way for > > this > > to be achieved, in a perfect world, is that this log entry be accompanied > > by a MESSAGE_ID, and HOST and CONNECTION_ID keys, and a catalog entry that > > combined > > with the keys, generates the above message so that grepping is entirely > > unnecessary. > > > > It is true that this perfect world is not just around the corner, or > > anything like that, > > but it is technically possible. > > > > I agree that grepping would be handy for me, right now, for just the > > reasons stated > > in the original message. > > > > I wonder if it would be reasonable for journalctl to supply the > > (additional) fields that are > > guaranteed to be associated with a MESSAGE_ID > And what what happen when the entry is "malformed", i.e. missing some fields? > Would journald reject the message? I don't think this would be useful to > anyone at all. Instead the readers of the message should gracefully adapt > to missing fields. > I think it would be wrong for journald to reject a message that does not supply all the declared fields. It would also be wrong for journalctl to crash when given the --catalog flag if the fields are missing. I don't know what it does right now, because it is not that easy a situation to engineer, AFAICT. I guess the best thing would be to supply a special catalog message indicating that an error had occurred when trying to construct a catalog message. Something that indicated the fields that were missing that caused the error would be nice. Just so long as that didn't turn into an infinite loop, somehow. If somebody knows what journalctl does do in this situation, please pass that information along. Other consumers of log entries should behave in whatever manner seems best to them if a declared field is missing. What I'm looking for here is the best way for an application which wants to use the journaling facilities provided to publish useful information about its log entry API. The advantage of publishing it in the manner I've suggested is that journalctl could be very helpful about telling consumers of the journal what keys they should expect to see. Something like: journalctl --list-keys and maybe even a journal API for programmatic access to this information would be very nice. Of course, there are other ways for an application to publish its log entry API. But, it does seem odd for it to do this outside the structures that systemd has already set up, when it is an API for journal entries. Since this really is an API, with all the usual issues about versioning and so forth, it really is essential that the information be published somewhere, not laboriously extracted from a scan of the code by potential log entry consumers. > ... > > Is it reasonable to preface any MESSAGE_ID > > specific keys with the MESSAGE_ID, e.g., > > "9bb33380-fbfa-4d5b-88b5-6e6bb8a39124:KEY"? Or perhaps a double underscore, > > e.g., > > "__KEY" would do the trick? > MESSAGE_ID is a contrace between the writers of the message and the readers > of > the message. The first say: messages with this ID mean ... and have have the > fields ... . There is no need to mark the fields in any other way, > except by documentation or custom. > > Zbyszek > The reason this seems important to me is the problem of a shared namespace. These MESSAGE_ID UUIDs are "globally" registered, since there is a high enough probability that every UUID is different that they are, to all intents and purposes, unique. But the keys do not have this advantage. In this shared namespace, it would be easy enough for journald to "steal" a key that was already in use by another application. This would generate all the obvious and usual problems, most p
Re: [systemd-devel] RFC: filter and search journalctl
On Mon, Aug 17, 2015 at 10:24:22AM -0400, Anne Mulhern wrote: > > > > > - Original Message - > > From: "Zbigniew Jędrzejewski-Szmek" > > To: "Sebastian Schindler" > > Cc: systemd-devel@lists.freedesktop.org > > Sent: Saturday, August 8, 2015 3:48:30 PM > > Subject: Re: [systemd-devel] RFC: filter and search journalctl > > > > On Fri, Aug 07, 2015 at 11:53:13AM +0200, Sebastian Schindler wrote: > > > Grep-ing seems to be the only solution to find log entries if you don't > > > fully > > > know what you're looking for. For example: You want to see all entries > > > containing a certain MESSAGE that gets enriched with additional > > > information > > > during the logging process: > > > > > > MESSAGE=host has closed connection > > This is a bit contentious, but at least I would like to see some > > grep functionality implemented directly in journalctl. > > > > I am late to the party, but I think it is obvious that the "right" way for > this > to be achieved, in a perfect world, is that this log entry be accompanied > by a MESSAGE_ID, and HOST and CONNECTION_ID keys, and a catalog entry that > combined > with the keys, generates the above message so that grepping is entirely > unnecessary. > > It is true that this perfect world is not just around the corner, or anything > like that, > but it is technically possible. > > I agree that grepping would be handy for me, right now, for just the reasons > stated > in the original message. > > I wonder if it would be reasonable for journalctl to supply the (additional) > fields that are > guaranteed to be associated with a MESSAGE_ID And what what happen when the entry is "malformed", i.e. missing some fields? Would journald reject the message? I don't think this would be useful to anyone at all. Instead the readers of the message should gracefully adapt to missing fields. ... > Is it reasonable to preface any MESSAGE_ID > specific keys with the MESSAGE_ID, e.g., > "9bb33380-fbfa-4d5b-88b5-6e6bb8a39124:KEY"? Or perhaps a double underscore, > e.g., > "__KEY" would do the trick? MESSAGE_ID is a contrace between the writers of the message and the readers of the message. The first say: messages with this ID mean ... and have have the fields ... . There is no need to mark the fields in any other way, except by documentation or custom. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: filter and search journalctl
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Sebastian Schindler" > Cc: systemd-devel@lists.freedesktop.org > Sent: Saturday, August 8, 2015 3:48:30 PM > Subject: Re: [systemd-devel] RFC: filter and search journalctl > > On Fri, Aug 07, 2015 at 11:53:13AM +0200, Sebastian Schindler wrote: > > Grep-ing seems to be the only solution to find log entries if you don't > > fully > > know what you're looking for. For example: You want to see all entries > > containing a certain MESSAGE that gets enriched with additional information > > during the logging process: > > > > MESSAGE=host has closed connection > This is a bit contentious, but at least I would like to see some > grep functionality implemented directly in journalctl. > I am late to the party, but I think it is obvious that the "right" way for this to be achieved, in a perfect world, is that this log entry be accompanied by a MESSAGE_ID, and HOST and CONNECTION_ID keys, and a catalog entry that combined with the keys, generates the above message so that grepping is entirely unnecessary. It is true that this perfect world is not just around the corner, or anything like that, but it is technically possible. I agree that grepping would be handy for me, right now, for just the reasons stated in the original message. I wonder if it would be reasonable for journalctl to supply the (additional) fields that are guaranteed to be associated with a MESSAGE_ID, and how this information might be registered. One way is to essentially derive this from an associated catalog entry, if any. Any fields that the catalog entry uses really ought to be supplied along w/ the MESSAGE_ID. This mapping is available to any human being, of course, by inspecting journal entries. But it also seems likely that there might be fields that should be guaranteed to accompany a MESSAGE_ID that should not be incorporated into a catalog message. I would be interested in the idea of, e.g., extending the format of the catalog file that an application distributes to allow an extra line that specifies guaranteed fields, or alternatively, to allow an additional file, dedicated to specifying this interface. This is a bit analogous to the interface file that is specified for foreign language bindings for a library. I'm also curious about a mechanism to distinguish those entries that are supplied specifically for a particular MESSAGE_ID from those that are, e.g., auto-generated by systemd or derived from some other sources. systemd has already taken the underscore for the unfakeable entries it provides. Is it reasonable to preface any MESSAGE_ID specific keys with the MESSAGE_ID, e.g., "9bb33380-fbfa-4d5b-88b5-6e6bb8a39124:KEY"? Or perhaps a double underscore, e.g., "__KEY" would do the trick? <-- SNIP --> > > Zbyszek > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network configuration
On Mon, 17.08.15 13:25, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > Well, actually, are things like ip rules never used? That's not what I am saying. All I am saying is that we should our homework and check if it is before exposing it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why is my docked idle laptop suspended?
On Fri, Aug 14 2015, Lennart Poettering wrote: > On Thu, 13.08.15 22:53, Michal Sojka (sojk...@fel.cvut.cz) wrote: > >> Hi list, >> >> I'm trying to figure out why is my laptop automatically suspended after >> being idle in a docking station. As far as I understand, logind should >> not suspend when the laptop is docked or external monitor is connected. >> >> Below is the (partially filtered) system log of what happens before the >> suspend. Things start at 17:34:09 when my screensaver sets IdleHint. Few >> minutes later (17:37) something happens and the logind suspends the >> system. I don't expect that network manager, active at the same time, >> can cause this. >> >> When looking at function manager_is_docked_or_external_displays(), when >> my system is docked, I should see "System is docked." message, but >> instead I see "External (1) displays connected." Can it be that the >> monitor powers down automatically and logind suspends the system because >> it is not aware of being docked? > > Note that systemd will print "System is docked" only if there's an > actual "docking" state known, i.e. via some input device that is > connected to the hinge of your laptop. Most laptops don't expose > this. In that case we count external displays, and then you only see > the "External displays connected" message, instead. > > Which version of systemd are you running? The one from Debian unstable $ systemd --version systemd 224 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN > Maybe some other usperspace service is triggering the suspend? Currently I suspect NetworkManager for triggering suspend. See the logs below. I have minimalist session with i3 window manager and xss-lock. >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message >> type=method_call sender=:1.39 destination=:1.224 >> object=/org/freedesktop/login1/session/_32 >> interface=org.freedesktop.login1.Session member=SetIdleHint cookie=34 >> reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message >> type=method_call sender=n/a destination=org.freedesktop.DBus >> object=/org/freedesktop/DBus interface=org.freedesktop.DBus >> member=GetConnectionUnixUser cookie=3105 reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message >> type=method_return sender=org.freedesktop.DBus destination=:1.224 object=n/a >> interface=n/a member=n/a cookie=2170 reply_cookie=3105 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal >> sender=n/a destination=n/a object=/org/freedesktop/login1/session/_32 >> interface=org.freedesktop.DBus.Properties member=PropertiesChanged >> cookie=3106 reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal >> sender=n/a destination=n/a object=/org/freedesktop/login1/seat/seat0 >> interface=org.freedesktop.DBus.Properties member=PropertiesChanged >> cookie=3107 reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal >> sender=n/a destination=n/a object=/org/freedesktop/login1/user/_1000 >> interface=org.freedesktop.DBus.Properties member=PropertiesChanged >> cookie=3108 reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal >> sender=n/a destination=n/a object=/org/freedesktop/login1 >> interface=org.freedesktop.DBus.Properties member=PropertiesChanged >> cookie=3109 reply_cookie=0 error=n/a >> Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: scan all >> dirs >> Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: >> scanning /sys/bus >> Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: >> scanning /sys/class >> Aug 13 17:34:09 steelpick systemd-logind[16201]: External (1) displays >> connected. >> Aug 13 17:34:09 steelpick systemd-logind[16201]: Refusing operation, as it >> is turned off. >> ... > > I'd would be nice to see what's going on here... Only this: Aug 13 17:37:48 steelpick dhclient[22949]: DHCPREQUEST on wlan0 to 147.32.208.3 port 67 Aug 13 17:37:48 steelpick dhclient[22949]: DHCPACK from 147.32.208.3 Aug 13 17:37:48 steelpick NetworkManager[1420]: address 147.32.219.249 Aug 13 17:37:48 steelpick NetworkManager[1420]: plen 22 (255.255.252.0) Aug 13 17:37:48 steelpick NetworkManager[1420]: gateway 147.32.216.1 Aug 13 17:37:48 steelpick NetworkManager[1420]: server identifier 147.32.208.3 Aug 13 17:37:48 steelpick NetworkManager[1420]: lease time 600 Aug 13 17:37:48 steelpick NetworkManager[1420]: nameserver '147.32.192.2' Aug 13 17:37:48 steelpick NetworkManager[1420]: nameserver '147.32.192.3' Aug 13 17:37:48 steelpick NetworkManager[1420]: domain name 'feld.cvut.cz' >> Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): DHCPv4 >> state changed bound -> bound >> Aug
Re: [systemd-devel] network configuration
On Mon, Aug 17, 2015 at 2:25 PM, Michał Zegan wrote: > Well, actually, are things like ip rules never used? > It could be a specific use case, but is this a category of never used > stuff, or legacy stuff? I do not use them myself, but I am curious. > I kind of wish networkd or NetworkManager could add rules for source-based routing by default – it would make some configurations (like two default routes) much easier to use... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network configuration
Well, actually, are things like ip rules never used? It could be a specific use case, but is this a category of never used stuff, or legacy stuff? I do not use them myself, but I am curious. W dniu 16.08.2015 o 15:09, Lennart Poettering pisze: On Fri, 14.08.15 19:50, Michał Zegan (webczat_...@poczta.onet.pl) wrote: Actually what is a procedure for more complicated network configuration, where you do not have something in networkd? Well, we try to cover a good chunk of the usecases, but we want be conservative when exposing options, to make this not more complex and overwhelming than it already is. For example, options people never actually use or that are clearly legacy don't need to be exposed. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
