HI,
While reading this I'm just thinking about RFC5880 ff. BFD support. Anybody in
the
networks universe already thinking about this?
Holger
- On 23 Jan, 2015, at 18:20, Alin Rauta alin.ra...@intel.com wrote:
Hi,
Uplink Failure Detection (UFD) is a key enhancement to networkd, that
Hi, sorry for delay in reply..
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 those messages are stored in /run/log,
and then flushed to /var/log, and the uploader
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
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,
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
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
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
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
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
just a small off topic question here. How far is IPv6 support in
networks incl. DHCPv6?
Many thanks and a happy new year!
Holger
--
Holger Winkelmann
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
Hi
By writing distributed applications we will look further for log
aggregation in the style of the systems-journal-gateway.
Regarding this I would like to know about the idea and plans of
the systemd community. Following the emails about logger optimization
Lennart mentioned something
Hi,
We have just released the Erlang Binding ejournald [1] for the journal. It
exposes the journal native
API to log natively and query the journal.
There is also a Erlang lager_journald_backend [2] which can be used for Erlang
applications.
[1] https://github.com/travelping/ejournald
[2]
Hi David,
- Original Message -
On Wed, Dec 18, 2013 at 10:32 AM, Holger Winkelmann [TP]
h...@travelping.com wrote:
with HTTP you need to setup another server and provide a Call back URL
Folks seem to increasingly call this pattern web hooks.
I know, but i tried to avoid to use
Hi all,
we are following the discussion initiated by Cecil about systemd
journal for a while. The last couple of weeks we have developed
a Erlang adapter for the journal to allow structured native logging.
Therefore we have developed a ejournald [1] backend for the Erlang
logging framework lager
Hi,
Is there any particular reason? I think thresold for runtime journal
size can lower much because in initramfs it's not supposed to have much
logs.
First, there are some data strcutures which are allocated when the file
is created, and if the file was very small, relatively more
Hi Cecil,
- Original Message -
After giving a presentation about systemd/journald I am seen as the
expert, so they come to me with the challenges they see.
As I understand it, journald is mend to log locally. Two methods to log
centrally are, if I have understand it correctly:
-
Hi,
- Original Message -
On Saturday 30 November 2013 19:30:12 you wrote:
There are standard dbus PropertiesChanged signals sent out for ActiveState
changes, which invalidate the properties when they change in released
versions of systemd, and which carry the new values along in
Hi Lennart,
Thanks for pointing this out...
There are standard dbus PropertiesChanged signals sent out for ActiveState
changes, which invalidate the properties when they change in released
versions of systemd, and which carry the new values along in git.
We probably should document which
Hi Dan,
- Original Message -
Hi,
Having watched the discussion over the past week or so, I'm left with a
few questions:
1) what is lacking in other userspace solutions (NetworkManager,
ConnMan, wicked, initscripts, etc) that requires
yet-another-network-daemon?
2) do you
sorry for double post after bounce and the huge signature,
messed up my mail client config a bit..
Holger
We asked our self the same questions, and alternatives exists even from
the embedded camp [1] which often comes close to the server use case.
Even if [1] does not have a Dbus interface,
Hi,
To clarify this: systemd-networkd is supposed to cover the initrd,
container, server and (some) embedded usecases. However, use NM or
connman for the interactive stuff (like wlans and suchlike) you need
on laptops/desktops and mobile.
Will this cover the UseCase of having a DHCP enabled
A native and fast DHCP client will be part of it, yes, it is needed in
the initrd.
Not sure though when we will get there though.
nice to hear. and right, having it in initrd is nice too.
currently we integrate http://0pointer.de/lennart/projects/ifplugd/
Urks, the 90s calling. :)
good morning,
We really like to see this direct, how ever would it not better to join
efforts for network management. I.e. arch Linux claims with netctl [1]
to do network management the systems way. and there are a few other
attempts to do network managent. I.e. netconfd [2] of openWRT is doing
And make acceptance tests on such machines ;-)
- Original Message -
'Twas brillig, and Kay Sievers at 18/03/13 10:42 did gyre and gimble:
On Mon, Mar 18, 2013 at 5:06 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Mar 17, 2013 at 02:54:01PM +0100, Kay Sievers
You are right, hopefully systemd will not turn into a direction
where only the ulra modern notebook or desktop can use it.
we see a lot of advantages to use systemd in embedded environments.
and we are talking here about_
- 180-680 MHh MIPS, ARM CPUs
- 4-32 MB Flash
- 32-128MB RAM
at the low
Hi all,
The room is gone...
Holger
- Original Message -
Hi,
One of our Guys is off sick and cant attend the Hackfest.
So we have a room free in the Avanti Hotel from 21st - 22rd Feb.
Anybody interested? Let me know the next hour please.
BR,
Holger
--
Holger
Hi Eduardo,
Hi Holger,
I think we have to blame the uninformed complaints that Systemd is
only for the desktop because of Dbus.
I was aware of this, but being a freedesktop project this not always
feels server alike.
Dbus can be built without X support. On Gimokod Linux the compressed
On Dec 4, 2011, at 4:40 PM, Kay Sievers wrote:
For very simple setups, the D-Bus bus daemon is not absolutely
necessary, and can probably be made optional with a few changes, but
the D-Bus protocol is used by systemctl to talk to systemd, and can
not really be optimized out.
systemctl
28 matches
Mail list logo
