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 ../src/libsystemd-network/sd-dhcp-cli
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
R
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 they
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 the
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 jus
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
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 remo
On Thu, Dec 11, 2014 at 9:14 AM, Jan Synáček 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(). Ignoring.
> Asser
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
Hi
On Wed, Dec 10, 2014 at 8:00 PM, Torstein Husebø 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 code comments
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.
>
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
>
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 sysl
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
>
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 sol
Signed-off-by: Alin Rauta
---
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 | 357 +
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 fa
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
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
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.
> >
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 b
HI,
>> Would the upload tool learn a new URL for this purpose i.e.
>> syslog://: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
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 net
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 c
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
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 diff
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
___
sy
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 cop
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]
MACAddress=44:44:12
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 cur
would this work the same for VXLAN?
On Thu Dec 11 2014 at 11:59:05 AM Rauta, Alin 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 44:44:12:34:56:7
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 th
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 cr
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__ ((__section_
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
d
38 matches
Mail list logo
