Hi,
test-dhcp-{client,server} are failing in mock:
FAIL: test-dhcp-client
==
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:138,
function sd_dhcp_client_set_request_option(). Ignoring.
Assertion 'client' failed at
Hey Guys,
We're running Arch Linux kernel-3.15 with lxc containers, systemd 215
without any issue.
But with 3.17 + systemd 217 we have very strange issues:
We have this target file:
[root@i-8452c468 system]# cat /home/wooh/container/system/container.target
[Unit]
Description=container.target
Just one more additional information:
So if I have already started the container and I stopped it, on the next
start up, it's not deleting the links at all, so this is very strange to
me. The links are the same, just links, no special attributes, same rights
as before, but on the first but up
HI,
Our embedded distribution relies on the systemd tooles including
journal based logging.
However there is a need to forward log messages to remote syslog.
We try to avoid to introduce a full blown syslog solution
like i.e. rsyslog to just forward log messages to a remote syslog server.
Is
On 12/11/2014 10:28 AM, Holger Winkelmann [TP] wrote:
HI,
Our embedded distribution relies on the systemd tooles including
journal based logging.
However there is a need to forward log messages to remote syslog.
We try to avoid to introduce a full blown syslog solution
like i.e. rsyslog to
On 12/10/2014 10:19 AM, Francis Moreau wrote:
Hello,
On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19,
On Thu, Dec 11, 2014 at 10:55:27AM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 10:28 AM, Holger Winkelmann [TP] wrote:
HI,
Our embedded distribution relies on the systemd tooles including
journal based logging.
However there is a need to forward log messages to remote syslog.
We
On Thu, Dec 11, 2014 at 9:14 AM, Jan Synáček jsyna...@redhat.com wrote:
test-dhcp-{client,server} are failing in mock:
FAIL: test-dhcp-client
==
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:138,
function sd_dhcp_client_set_request_option().
Hi,
However there is a need to forward log messages to remote syslog.
We try to avoid to introduce a full blown syslog solution
like i.e. rsyslog to just forward log messages to a remote syslog server.
What Jóhann describes should work, even though it is a bit hacky.
There is also a TODO
Hi
On Wed, Dec 10, 2014 at 8:00 PM, Torstein Husebø torst...@huseboe.net wrote:
Hi,
this patch set inserts missing spaces and newlines in code comments.
No code change.
Torstein Husebø (6):
networkd/resolved: correct spacing near eol in code comments
sd-bus: correct spacing near eol in
On Thu, Dec 11, 2014 at 01:56:24PM +, Holger Winkelmann [TP] wrote:
Hi,
However there is a need to forward log messages to remote syslog.
We try to avoid to introduce a full blown syslog solution
like i.e. rsyslog to just forward log messages to a remote syslog server.
What Jóhann
HI,
Are there any plans to follow? I.e, having all protocols in a generic
gateway,
or having one gateways per protocol? How the should we define which field
form the journal should be forwarded to syslog?
IIUC, Lennart wanted to add this funcitonality to systemd-journal-upload or
a new
On Thu, Dec 11, 2014 at 02:54:18PM +, Holger Winkelmann [TP] wrote:
HI,
Are there any plans to follow? I.e, having all protocols in a generic
gateway,
or having one gateways per protocol? How the should we define which field
form the journal should be forwarded to syslog?
IIUC,
Hi,
upload sounds a bit of a batch process, but thats just cosmetic wording.
Having this in systems-journald and extend the forward to syslog config with
the
target
host was our expectation anyway.
The difference is in how the logs are accessed: if journald itself does the
jobs,
they
On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
The difference is in how the logs are accessed: if journald itself does the
jobs,
they would be forwarded live. If anything else, the uploader would be a client
which reads the files in/var/log/journal/. The are advantages to both
Signed-off-by: Alin Rauta alin.ra...@intel.com
---
Makefile.am | 1 +
man/systemd.network.xml | 31 +++
src/libsystemd/sd-rtnl/rtnl-message.c| 56 -
src/libsystemd/sd-rtnl/rtnl-types.c | 15 +-
src/network/networkd-fdb.c
Hi,
I've added support for handling the forwarding database table for a port.
FDB entries can be configured statically through the .network files.
To resume,
- I've added a new boolean for the main network structure, named
FDBControlled which is read from the .network file and defaults to
On Thu, Dec 11, 2014 at 03:39:56PM +, Holger Winkelmann [TP] wrote:
Hi,
upload sounds a bit of a batch process, but thats just cosmetic wording.
Having this in systems-journald and extend the forward to syslog config
with the
target
host was our expectation anyway.
The
On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote:
Hi,
I've added support for handling the forwarding database table for a port.
FDB entries can be configured statically through the .network files.
To resume,
- I've added a new boolean for the main network structure, named
On 12/11/2014 04:07 PM, Alin Rauta wrote:
[Network]
DHCP=v4
FDBControlled=yes
[FDBEntry]
MACAddress=44:44:12:34:56:71
VLAN=9
[FDBEntry]
MACAddress=44:44:12:34:56:72
VLAN=10
Any reason why you are adding a boolean variable here --
FDBControlled=yes --
It should be safe to assume if any
On Thu, 11.12.14 17:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I agree with your findings, and basically thats how the zmq journal gateway
works as
well. And thanks to bring the wait for network up here, you would miss
important
boot log entries here.
Would the
On Thu, Dec 11, 2014 at 04:09:54PM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
The difference is in how the logs are accessed: if journald itself does the
jobs,
they would be forwarded live. If anything else, the uploader would be a
HI,
Would the upload tool learn a new URL for this purpose i.e.
syslog://ip:514 ?
Or a broadcast address, so no configuration is required.
Hmmm. Admin guys would not really like broadcast here. But anyway would not
argue
much if it can be configured.
Initial plan was to implement the
On Thu, Dec 11, 2014 at 05:18:58PM +0100, Lennart Poettering wrote:
On Thu, 11.12.14 17:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I agree with your findings, and basically thats how the zmq journal
gateway works as
well. And thanks to bring the wait for network up
HI,
Or a broadcast address, so no configuration is required.
I'd really like to see broadcast delivery I must say.
as mentioned, why not if it can switched off and unicasted to the IP:514
That's rfc5424, right? Then yes.
Is that RFC actually widely adopted? I'd stay as conservative
On 12/11/2014 04:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 11, 2014 at 04:09:54PM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
The difference is in how the logs are accessed: if journald itself does the
jobs,
they would be
On Thu, Dec 11, 2014 at 04:35:24PM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 04:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 11, 2014 at 04:09:54PM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
The difference is in how the
On 12/11/2014 04:38 PM, Zbigniew Jędrzejewski-Szmek wrote:
You need an address to establish a socket. And the socket queue will not
be enough if you have copious debug or kernel messages.
Cant we just tweak those values to suit our needs?
JBG
___
On Thu, Dec 11, 2014 at 04:43:25PM +, Jóhann B. Guðmundsson wrote:
On 12/11/2014 04:38 PM, Zbigniew Jędrzejewski-Szmek wrote:
Cant we just tweak those values to suit our needs?
You need an address to establish a socket.
No.
And the socket queue will not
be enough if you have copious
On 12/11/2014 04:16 PM, Lennart Poettering wrote:
What happens if FDBControlled is no, but still FDBEntrys specified?
Cant we simply address those no/yes cases by extending the [Install]
section to cover all those [foo] entries
Something like..
[Network]
DHCP=v4
[FDB]
Hi Lennart,
Thanks for your quick response.
Regarding the naming FDBEntry. My inspiration was the bridge tool command.
To add an entry using bridge command:
bridge fdb add 44:44:12:34:56:73 dev em1 vlan 10
If FDBControlled is no (default value) then the forwarding database table
for current
would this work the same for VXLAN?
On Thu Dec 11 2014 at 11:59:05 AM Rauta, Alin alin.ra...@intel.com wrote:
Hi Lennart,
Thanks for your quick response.
Regarding the naming FDBEntry. My inspiration was the bridge tool
command.
To add an entry using bridge command:
bridge fdb add
Hi Johann,
If FDBControlled is no then we don't want to touch the forwarding database
table for this port.
If it's yes, then we want to control the FDB table (delete existing entries).
[Install] section can be an alternative. What about FDB=enable ? - in case we
want to add something else to
On 12/11/2014 05:07 PM, Rauta, Alin wrote:
Hi Johann,
If FDBControlled is no then we don't want to touch the forwarding database
table for this port.
If it's yes, then we want to control the FDB table (delete existing entries).
[Install] section can be an alternative. What about FDB=enable ?
I'm not quite following what you said there but I would actually
think the former as in forward it live is better, ju
Journal carries messages from the initramfs. We cannot send them from
the initramfs, unless we bring up the network then, which we don't want
to do just for this purpose. But
Trying to build 218 but I am getting undefined reference error. The
source code of bus-error.c mentions that gcc magically maps these
variables but not for me.
What is doing the mapping? __attribute__ ((__section__(BUS_ERROR_MAP))) ?
Could it be that mentioned gcc magic is not supported on cross
On Thu, 11.12.14 23:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
Trying to build 218 but I am getting undefined reference error. The
source code of bus-error.c mentions that gcc magically maps these
variables but not for me.
What is doing the mapping? __attribute__
Hi,
Lennart:
The idea is that any .c file linked into a binary can define
additional maps, and we collect them all simply by iterating through
__start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP.
Unless there are none of these entries.
Umut: Does the cross compiling somehow not include any
data
38 matches
Mail list logo
