Re: [systemd-devel] udev virtio by-path naming

On 27.02.2017 12:22, Michal Sekletar wrote: > On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski > wrote: >> On 20.02.2017 17:00, Cornelia Huck wrote: >>> On Mon, 20 Feb 2017 15:34:49 +0100 >>> Viktor Mihajlovski wrote: >>> Hi,

Re: [systemd-devel] systemd debug out of memory

On Tue, 28.02.17 13:26, Pascal kolijn (p.kol...@vu.nl) wrote: > Hi List, > > I've subscribed to this list to ask for help in debugging a problem we > seem to have with the socket activated telnetd on a rhel7 system. > > A default install of telnetd collects data from some small boxes > deployed

Re: [systemd-devel] journald disk space usage

On Mon, 27.02.17 16:18, Bill Lipa (d...@masterleep.com) wrote: > Hello, > > I have a Rails application that produces quite a bit of log output - > about 500MB per day, maybe 3-4 million lines. Currently this is going > into a normal file with daily rotation. > > I tried dumping this into

[systemd-devel] systemd debug out of memory

Hi List, I've subscribed to this list to ask for help in debugging a problem we seem to have with the socket activated telnetd on a rhel7 system. A default install of telnetd collects data from some small boxes deployed in the field. It works for a long time and then suddenly: Feb 26 17:46:53

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

On Mon, Feb 27, 2017 at 11:50:59PM -0300, Marcelo Tosatti wrote: > On Sun, Feb 26, 2017 at 09:52:18PM +0100, Lennart Poettering wrote: > > On Thu, 23.02.17 22:20, Marcelo Tosatti (mtosa...@redhat.com) wrote: > > > > > > > > Its necessary to specify the KVM PTP device name in userspace. > > > >

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

On Tue, Feb 28, 2017 at 04:54:00PM +, Daniel P. Berrange wrote: > > > Also, what's the benefit of shipping this upstream? Why not ship that > > > rule with kvm? > > > > qemu-kvm package? Sure i can do that, but then all distributions > > have to do the same with their own packages. > >

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

On Sun, Feb 26, 2017 at 09:52:18PM +0100, Lennart Poettering wrote: > 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

Re: [systemd-devel] journald disk space usage

Thank you for the response. I was hoping that the metadata would compress better because it's almost identical between rows in my application. 99% of the rows are going to be from the same unit. On Tue, Feb 28, 2017 at 7:56 AM, Lennart Poettering wrote: > > The journal

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

On Tue, 28.02.17 16:54, Daniel P. Berrange (berra...@redhat.com) wrote: > On Mon, Feb 27, 2017 at 11:50:59PM -0300, Marcelo Tosatti wrote: > > On Sun, Feb 26, 2017 at 09:52:18PM +0100, Lennart Poettering wrote: > > > On Thu, 23.02.17 22:20, Marcelo Tosatti (mtosa...@redhat.com) wrote: > > > > >

[systemd-devel] Non-root service with CAP_NET_RAW

Does anyone know of a "howto" or similar that lists the steps that I need to take to run a service as a non-root user (nobody) with CAP_NET_RAW? I've tried adding CapabilityBoundingSet=CAP_NET_RAW to the [Service] section of my unit file, but it doesn't appear to be working. What else do I need

Re: [systemd-devel] udev virtio by-path naming

On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > One could argue about back-level compatibility, but virtio by-path > naming has changed multiple times. We have seen virtio-pci-virtio > (not predictable), pci- and virtio-pci- already. It > might be a good

Re: [systemd-devel] udev virtio by-path naming

01.03.2017 06:43, Zbigniew Jędrzejewski-Szmek пишет: > > We could keep an informal list of people who care about specific areas. MAINTAINERS file as part of systemd sources? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org

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

Lennart, On Mon, 2017-02-27 at 19:42 +0100, Lennart Poettering wrote: > On Mon, 27.02.17 08:29, Krzysztof Błaszkowski (k...@sysmikro.com.pl) > wrote: > > > > > > > > > The journal file format is primarily an append-based format > > > (though > > > some fields at the front are updated, to link

[systemd-devel] systemd dbus signal failure

*Hello.* *I am writing a systemd notifier via signals.* *It works when i stop/start/restart a service. ** * *The problems starts, when in 5 seconds later I trigger en error:* Mar 01 08:37:43 server webhook[2299]: Webhook listening on port 23500! Mar 01 08:37:48 server webhook[2299]:

Re: [systemd-devel] udev virtio by-path naming

On Tue, Feb 28, 2017 at 08:39:07PM +0100, Lennart Poettering wrote: > On Tue, 28.02.17 19:28, Daniel P. Berrange (berra...@redhat.com) wrote: > > The problem with splitting these rules out into a separate project > > is that there's no other existing place that they would live. The > > "virtio

Re: [systemd-devel] udev virtio by-path naming

On Wed, Mar 01, 2017 at 06:51:17AM +0300, Andrei Borzenkov wrote: > 01.03.2017 06:43, Zbigniew Jędrzejewski-Szmek пишет: > > > > We could keep an informal list of people who care about specific areas. > > MAINTAINERS file as part of systemd sources? Heh, I really didn't want to mention this ;)

Re: [systemd-devel] udev virtio by-path naming

On Mon, Feb 20, 2017 at 04:14:32PM +0100, Lennart Poettering wrote: > On Mon, 20.02.17 15:34, Viktor Mihajlovski (mihaj...@linux.vnet.ibm.com) > wrote: > > > But then, I find this naming scheme somewhat weird. > > A virtio disk shows up as a regular PCI function on the PCI > > bus side by side

Re: [systemd-devel] udev virtio by-path naming

On Tue, 28.02.17 19:28, Daniel P. Berrange (berra...@redhat.com) wrote: > > Even better would be if the kernel would do the naming on its own, and > > maybe just provide us with a sysattr on the relevant devices that we > > can read to determine the path from, so that we don#t have to maintain >

Re: [systemd-devel] Non-root service with CAP_NET_RAW

CapabilityBoundingSet is the exact opposite of what you need, then. It's the *bounding set*, it limits capabilities. With recent kernels, you'll probably want AmbientCapabilities= as the simplest option. (Can't remember when that was introduced though.) With older kernels you'll have to use the