[systemd-devel] systemd dbus signal failure

[Patrik Laszlo]

*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]: /root/server-scripts/webhook:26
Mar 01 08:37:48 server webhook[2299]: asdasd
Mar 01 08:37:48 server webhook[2299]: ^
Mar 01 08:37:48 server webhook[2299]: ReferenceError: asdasd is not defined
Mar 01 08:37:48 server webhook[2299]: at Timeout.setTimeout [as 
_onTimeout] (/root/server-scripts/webhook:26:5)

Mar 01 08:37:48 server webhook[2299]: at ontimeout (timers.js:365:14)
Mar 01 08:37:48 server webhook[2299]: at tryOnTimeout (timers.js:237:5)
Mar 01 08:37:48 server webhook[2299]: at Timer.listOnTimeout 
(timers.js:207:5)
Mar 01 08:37:48 server systemd[1]: p3x-webhook.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 01 08:37:48 server systemd[1]: p3x-webhook.service: Unit entered 
failed state.
Mar 01 08:37:48 server systemd[1]: p3x-webhook.service: Failed with 
result 'exit-code'.


*I catch all events:*

  UnitNew: 'UnitNew',
UnitRemoved: 'UnitRemoved',
JobNew: 'JobNew',
JobRemoved: 'JobRemoved',
StartupFinished: 'StartupFinished',
UnitFilesChanged: 'UnitFilesChanged',
Reloading: 'Reloading'*,*

*
**The question, how can I receive a signal when a service goes into a 
failed state or any other triggered exit code?*


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Krzysztof Błaszkowski]

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 the new additions
> > > up). This makes it not too bad when it comes to disk corruptions,
> > > and
> > > data up to the point of corruption should be readable pretty
> > > nicely
> > > still.
> > 
> > well, the most interesting information is located beyond that point
> > very often. 
> 
> Well, note that journald will stop writing to journal files as soon
> as
> it notices a corruption of any kind, and will start new journal
> files,
> leaving the old ones the way they are (thus not making them worse). 


Is there a way to access the data collected beyond the point of
corruption ? Notice that I lost logs for a month time because of system
freeze however my ext4 recovered and is clean but *-journal.

> We
> also start new journal files in regular intervals, after a fixed time
> interval or after a certain number of bytes wirtten, for whatever
> comes first.

splendid. this is like making poor candies more sweet.


> 
> With that in place I am pretty sure our behaviour when it comes to
> real-life corruptions these days isn't that bad: when something bad
> happens, then we'll conserve in time what has been written already,
> and if you destroy one file entirely what you loose will be bounded
> both in time and in size.
> 
> But anyway, I get the impression that you don't like the journal out
> of principle, and I am not sure I want to try to convince you
> otherwise.


right, it will not convince me because we differ in very basic points
of views. You agree for log losses "to some degree" (undefined) while I
reckon this is not acceptable utterly. And because I think that I'm
absolutely right that log losses are not acceptable then here is
logical conclusion: a syslogd replacement must do exactly what syslogd
used to do because if there are only milisecs to kernel failure left
then there is no time for various funny "database doings" like hashing,
indexing rows, compression - all that is rubbish. Logs must be appended
only to current log file all the time as fast as syslogd or its
replacement can do. Let filesystem do these things.

and many don't need one "sweety tool for dumbs" because they are
familiar with cat and grep. These various http crap admin idiots better
educate themself.


>  My recommendation would be: if you don't like it don't use
> it, set Storage=no in journald.conf and use whatever you like
> better. You'll still benefit from journald and systemd collecting
> all service stdout/stderr and early boot stuff for you, over plain
> sysvinit/syslog, but it won't store anything on disk for you anymore.
> 

ok. will give a try. Collected new battery yesterday and troubles gone.


> > 
> > > 
> > > Anyway, if you have a corrupted journal file and current
> > > journalctl
> > > can't read it, then please file a bug, attach the journal file,
> > > and
> > > we'll look into improving journalctl.
> > > 
> > 
> > journalctl --verify
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-
> > 1105.journal 
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005
> > 495e
> > 2bb26863-aa72c6a8a7437123.journal~
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005
> > 455b
> > e5e6181f-8616123458bd2b50.journal~
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005
> > 4956
> > b0c61ef7-6f0ef8bfd59ad5e8.journal~
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@0
> > 0054
> > 95e2c558675-4af46c2d79464765.journal~
> > 549f50: Invalid entry item (7/9 offset:
> > 00
> > 549f50: Invalid object contents: Bad
> > message  
> > File corruption detected at
> > /var/log/journal/52f04da61fa8108cd5f48bca58
> > 6164a2/system@0005495abfa1c9d8-cf2df0a23044.journal~:549f50 (of
> > 8388608 bytes, 66%).
> > FAIL: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005
> > 495a
> > bfa1c9d8-cf2df0a23044.journal~ (Bad message)
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/user-1000@0
> > 0054
> > 55bfdbeb23d-1ff3046498e945ad.journal~
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@0005
> > 495e
> > 3d56c587-44f1967167aac5a3.journal~
> > PASS: /var/log/journal/52f04da61fa8108cd5f48bca586164a2/system@65be
> > e6e3
> > 4f3c4b77b265431a1dd2a6df-0001-0005459b8fd2a11e.journal
> > c84f48: Invalid entry item (8/24 offset:
> > 00   
> > c84f48: Invalid object contents: Bad
> > message  
> > File corruption detected at
> > /var/log/journal/52f04da61fa8108cd5f48bca58
> > 

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

[Mantas Mikulėnas]

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 older Capabilities= setting *and*
set file capabilities (setcap) on the executable itself.

(Well, depending on what file caps you set you might not even need any
systemd settings at all... See e.g. "getcap /sbin/ping" as a fully
standalone example, iirc it uses "cap_foo=eip" for this.)

On Wed, Mar 1, 2017, 00:40 Ian Pilcher  wrote:

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 to do?

Thanks!

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Zbigniew Jędrzejewski-Szmek]

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 ;)
I don't think MAINTAINERS as such would work. I think we'd be better off
with a publicly editable wiki page somewhere on github.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Zbigniew Jędrzejewski-Szmek]

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 people" as a group merely write specifications. The actual
> > implementation of those specs is done by multiple other independant
> > groups - QEMU (for host side, though other host side impls exist
> > too) and Linux (for guest side). The udev rules are Linux guest
> > support pieces, but of course Linux itself doesn't distribute udev
> > rules - it delegated that job to the udev package hence why they
> > are here currently. So I don't see that pushing the rules out of
> > the udev repo would be beneficial to people building VMs.

Yeah, that's my view too. Those by-path symlinks are parts of the
basic functionality of the system, and it'd be unfortunate to require
yet another package to make them appear.

We've been there, done that, and too much fragmentation causes more
issues than it solves. The issue with those patches seems to be that
it's hard to find knowledgeable people to review them, but telling
those people to start a project of their own doesn't really help with
that, it just pushes the work around while adding overhead.

> The thing is simply that for these kinds of things it's not done with
> drive-by patches simply because we have noone right now who can review
> them with the right technical expertise.
> 
> So yeah, I am not totally against leaving them in the udev repo (Or to
> say this differently, I am much more interested to see the scsi stuff
> go somewhere else than the virtion stuff), but only if somebody steps
> up and takes up ownership of this, and does so continously.
> 
> No, this doesn't mean you have to subscribe to all systemd
> PRs/issues. It just means that this someone will react to being /cc'ed
> in the github repo sooner or later, and say something.

We could keep an informal list of people who care about specific areas.
This already functions to some extent, and we should just be more
consistent: for any issue, see who touched the code recently, and
mention them in the PR or issue, and for PRs, add people to the
reviewers list. Github the social coding site, ftw!

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Andrei Borzenkov]

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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Zbigniew Jędrzejewski-Szmek]

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 time now to settle on a common approach for all
>  virtio types.
> 
>  For the reasons above, I'd vote for -, which
>  would work for PCI and CCW, not sure about ARM MMIO though.

It seems that there's agreement that - is the right
approach.

Ideally we would keep the virtio-pci- links as they appear
right now, for backwards compatibility, just for the pci devices, and
mark them as deprecated (dunno where, maybe just in NEWS), and add the
code to make the links.

I haven't looked at the code, maybe we just do this with the right
udev rule, and also stick the deprecation comment there?

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Non-root service with CAP_NET_RAW

[Ian Pilcher]

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 to do?

Thanks!

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

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
> > this at all in userspace. That way, the driver folks on the kernel
> > side can use any naming they like without ever having to patch this
> > into systemd or udev.
> > 
> > This is similar to SCSI stuff and all things like that: the more
> > exotic it gets the less place this really has in systemd, we are not
> > the right maintainers for this. And given that this is all nicely
> > pluggable (you can ship your own udev extensions externally very
> > easily), there's really no reason for this to be in systemd/udev.
> 
> The other post about ptp-kvm rules reminded me that I wanted to
> respond to this mail too.
> 
> 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 people" as a group merely write specifications. The actual
> implementation of those specs is done by multiple other independant
> groups - QEMU (for host side, though other host side impls exist
> too) and Linux (for guest side). The udev rules are Linux guest
> support pieces, but of course Linux itself doesn't distribute udev
> rules - it delegated that job to the udev package hence why they
> are here currently. So I don't see that pushing the rules out of
> the udev repo would be beneficial to people building VMs.
> 
> > Anyway, I fear you're going to have a hard time involving us in a
> > technical discussions about the issue you are raising, since quite
> > frankly we have no clue about virtio...
> 
> Could it be as simple as having a couple of people nominated as the
> technical point of contact for the virtio rules, who can be CC'd
> to get answers any questions that may need answering ? I don't have
> time to actively monitor systemd pull requests for changes affecting
> virtio, but I'd be ok with being pinged if issues come up that need
> assistance & can pull in other virt experts where needed.

Well, yes, it boils down to having capable and interested maintainers
for this, who know the relevant udev bits well (or at least are
willing to figure out what they need ot know) and also knows virtio,
and will review these patches thoroughly, make sure they following
CODING_STYLE and so on..

The thing is simply that for these kinds of things it's not done with
drive-by patches simply because we have noone right now who can review
them with the right technical expertise.

So yeah, I am not totally against leaving them in the udev repo (Or to
say this differently, I am much more interested to see the scsi stuff
go somewhere else than the virtion stuff), but only if somebody steps
up and takes up ownership of this, and does so continously.

No, this doesn't mean you have to subscribe to all systemd
PRs/issues. It just means that this someone will react to being /cc'ed
in the github repo sooner or later, and say something.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daniel P. Berrange]

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 with other (non-virtio) devices. The naming otoh
> > suggests that virtio-pci is a subsystem of its own, which is simply
> > incorrect from a by-path perspective.
> > 
> > Using just the plain PCI path id is actually sufficient to identify
> > a virtio disk by its path. This would be in line with virtio
> > network interface path names which use the plain PCI naming.
> > 
> > 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 time now to settle on a common approach for all
> > virtio types.
> > 
> > For the reasons above, I'd vote for -, which
> > would work for PCI and CCW, not sure about ARM MMIO though.
> > Opinions?

Virtio MMIO devices are identified by a unique control register
base address. eg 0x3000. So I think - would
work fine to all cases PCI, CCW & MMIO.  Certainly it is moire
correct than hardcoding virtio-pci as a prefix - that's just
plain broken for non-PCI transports.

> So, to make this clear, we in systemd are kinda interested in
> splitting out these virtio helpers into some external project
> maintained by virtio peopl. We as systemd/udev maintainers have very
> little understanding of the underlying technology, so we can't really
> be any good maintainers of this, and we can't really comment on this
> stuff, in particular when it gets more exotic, like the CCW stuff.
> 
> 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
> this at all in userspace. That way, the driver folks on the kernel
> side can use any naming they like without ever having to patch this
> into systemd or udev.
> 
> This is similar to SCSI stuff and all things like that: the more
> exotic it gets the less place this really has in systemd, we are not
> the right maintainers for this. And given that this is all nicely
> pluggable (you can ship your own udev extensions externally very
> easily), there's really no reason for this to be in systemd/udev.

The other post about ptp-kvm rules reminded me that I wanted to
respond to this mail too.

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 people" as a group merely write specifications. The actual
implementation of those specs is done by multiple other independant
groups - QEMU (for host side, though other host side impls exist
too) and Linux (for guest side). The udev rules are Linux guest
support pieces, but of course Linux itself doesn't distribute udev
rules - it delegated that job to the udev package hence why they
are here currently. So I don't see that pushing the rules out of
the udev repo would be beneficial to people building VMs.

> Anyway, I fear you're going to have a hard time involving us in a
> technical discussions about the issue you are raising, since quite
> frankly we have no clue about virtio...

Could it be as simple as having a couple of people nominated as the
technical point of contact for the virtio rules, who can be CC'd
to get answers any questions that may need answering ? I don't have
time to actively monitor systemd pull requests for changes affecting
virtio, but I'd be ok with being pinged if issues come up that need
assistance & can pull in other virt experts where needed.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

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:
> > > 
> > > > 
> > > > 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 might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1. 
> > > > 
> > > > Fix a device name for the KVM PTP device.
> > > 
> > > What's the symlink precisely good for, can you elaborate? 
> > 
> > You want to configure Chrony to use PTP in the guest to sync with the
> > host.
> > 
> > You need to add a entry to /etc/chrony.conf pointing to "/dev/ptp0", 
> > the ptp_kvm device.
> > 
> > However, it might be the case that a PCI assigned device has a PTP
> > clock, and it can be registered as "/dev/ptp0" and ptp_kvm as
> > "/dev/ptp1".
> > 
> > > 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.
> 
> qemu-kvm is installed in the host OS only, but this rule needs to be
> set in the guest OS, unless you want to bundle it in with qemu-guest-agent
> RPM, but that's not really a directly related package, so we'd liekly have
> to create a new package for this and try and get distros to ensure it is
> installed in all guest OS. We've had qemu-guest-agent for years now and
> we've still not got all distros installing it. So not shipping this kind
> of rule with udev means that it'll almost certainly end up being missing
> in the majority of guest installs for many years to come.

Thank you for the explanation. This was what I was looking for.

I generated a github PR now from this:

https://github.com/systemd/systemd/pull/5495

Marcelo, it's generally preferable these days to submit via github PRs
right-away.

Let's continue discussion on the github PR. Thanks.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald disk space usage

[Bill Lipa]

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 generates substantially more data, simply because we
> collect a lot of implicit metadata for each log even. This data is
> usually not compressed (we only compress individually large fields,
> and usually fields are not individuall large). The implicit metadata
> means we roughly collect 10x as much data and store that away.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Tomasz Torcz]

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.
> 
> qemu-kvm is installed in the host OS only, but this rule needs to be
> set in the guest OS, unless you want to bundle it in with qemu-guest-agent
> RPM, but that's not really a directly related package, so we'd liekly have
> to create a new package for this and try and get distros to ensure it is
> installed in all guest OS. We've had qemu-guest-agent for years now and
> we've still not got all distros installing it. So not shipping this kind
> of rule with udev means that it'll almost certainly end up being missing
> in the majority of guest installs for many years to come.

  If distros do not care about optimal performance, why would we care
and try to make everyone happy by sneaking this change in udev?
  If this feature is important to end user, then the user should change
the distribution to one providing the feature.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Daniel P. Berrange]

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.
> > > 
> > > In case a network card with PTP device is assigned to the guest,
> > > it might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1. 
> > > 
> > > Fix a device name for the KVM PTP device.
> > 
> > What's the symlink precisely good for, can you elaborate? 
> 
> You want to configure Chrony to use PTP in the guest to sync with the
> host.
> 
> You need to add a entry to /etc/chrony.conf pointing to "/dev/ptp0", 
> the ptp_kvm device.
> 
> However, it might be the case that a PCI assigned device has a PTP
> clock, and it can be registered as "/dev/ptp0" and ptp_kvm as
> "/dev/ptp1".
> 
> > 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.

qemu-kvm is installed in the host OS only, but this rule needs to be
set in the guest OS, unless you want to bundle it in with qemu-guest-agent
RPM, but that's not really a directly related package, so we'd liekly have
to create a new package for this and try and get distros to ensure it is
installed in all guest OS. We've had qemu-guest-agent for years now and
we've still not got all distros installing it. So not shipping this kind
of rule with udev means that it'll almost certainly end up being missing
in the majority of guest installs for many years to come.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Marcelo Tosatti]

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 might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1. 
> > 
> > Fix a device name for the KVM PTP device.
> 
> What's the symlink precisely good for, can you elaborate? 

You want to configure Chrony to use PTP in the guest to sync with the
host.

You need to add a entry to /etc/chrony.conf pointing to "/dev/ptp0", 
the ptp_kvm device.

However, it might be the case that a PCI assigned device has a PTP
clock, and it can be registered as "/dev/ptp0" and ptp_kvm as
"/dev/ptp1".

> 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.

Why not do it in a centralized location where everyone benefits?
(other virtual devices such as virtio-serial already have aliases
upstream).

> Lennart
> 
> -- 
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald disk space usage

[Lennart Poettering]

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 journald via STDOUT so that I could see
> everything in one place.  On a standard Google Cloud Platform
> instance, this used about 10% extra CPU.  I was willing to live with
> that, but more of a problem was the rapid increase in storage used for
> the log.  It was growing at about 10x the rate as a flat file for the
> 2 hours I ran the experiment.  That is, after 2 hours, the usage
> reported by 'sudo journalctl --disk-usage' was over 400MB, which is
> not much less than I would normally see for an entire day's worth of
> logging.
> 
> I am wondering if this is to be expected due to journald's extra
> functionality and complexity, or does this seem incorrect?  I'm using
> systemd 229 on Ubuntu 16.04.

The journal generates substantially more data, simply because we
collect a lot of implicit metadata for each log even. This data is
usually not compressed (we only compress individually large fields,
and usually fields are not individuall large). The implicit metadata
means we roughly collect 10x as much data and store that away. This is
easy to verify:

journalctl -n 1000 | wc -c

vs.

journalctl -n 1000 -o verbose | wc -c

The first command outputs the journal data in syslog compatible
format, thus lacking all metadata. THe second command uses "verbose"
output mode, which includes all metadata. We output that for the 1000
most recent log events. On my system this yields 101993 and 971434.

If you are not interested in the metadata and systemd's indexing you
can of course turn off journald's storage and use something
non-indexed that carries no metadata, such as rsyslog or so.

Also note that beyond the mere metadata we also tend to collect more
data, simply because we also hook into audit, and every service's
stdout/stderr, as well as early boot logging, which syslog
traditionally didn't do this level.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

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 in the field. It works for a long time and then suddenly:
> 
> Feb 26 17:46:53 bibr systemd: Created slice user-6006.slice.
> Feb 26 17:46:53 bibr systemd: Starting user-6006.slice.
> Feb 26 17:46:53 bibr systemd: Started Session 2223341 of user .
> Feb 26 17:46:53 bibr systemd-logind: New session 2223341 of user .
> Feb 26 17:46:53 bibr systemd: Starting Session 2223341 of user .
> Feb 26 17:46:53 bibr systemd: Started Telnet Server (:28830).
> Feb 26 17:46:53 pbibr001 systemd: Starting Telnet Server (:28830)...
> Feb 26 17:46:57 bibr systemd: Failed to fork: Cannot allocate memory

Hmm, Linux fork() returns ENOMEM if the maximum number of tasks on the
system is hit (yes this is a bit misleading, but that's how it is).
That max number of tasks is limited for example by the max number of
assignable pids as configured in /proc/sys/kernel/pid_max? Maybe you
hit that limit? Maybe something is leaking pids on your system? not
reaping zombies properly?

> Feb 26 17:46:57 bibr systemd: Assertion 'pid >= 1' failed at
> src/core/unit.c:1996, function unit_watch_pid(). Aborting.
> Feb 26 17:46:57 bibr001 systemd: Caught , cannot fork for core
> dump: Cannot allocate memory
> Feb 26 17:46:57 bibr systemd: Freezing execution.

So this is definitely a bug. If the limit is hit, we hould certainly
not hit an assert. I tried to figure out how this could ever happen,
but afaics this should not be possible on current git at least. Any
chance you can try to reproduce this isue with something more recent
than a rhel7 box?

Either way it appears that there's both a bug on your setup and in
systemd: something leaks processes (which is bug #1, in your setup)
and then systemd doesn't deal properly with that (which is bug #2, in
systemd upstream)...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd debug out of memory

[Pascal kolijn]

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 bibr systemd: Created slice user-6006.slice.
Feb 26 17:46:53 bibr systemd: Starting user-6006.slice.
Feb 26 17:46:53 bibr systemd: Started Session 2223341 of user .
Feb 26 17:46:53 bibr systemd-logind: New session 2223341 of user .
Feb 26 17:46:53 bibr systemd: Starting Session 2223341 of user .
Feb 26 17:46:53 bibr systemd: Started Telnet Server (:28830).
Feb 26 17:46:53 pbibr001 systemd: Starting Telnet Server (:28830)...
Feb 26 17:46:57 bibr systemd: Failed to fork: Cannot allocate memory
Feb 26 17:46:57 bibr systemd: Assertion 'pid >= 1' failed at
src/core/unit.c:1996, function unit_watch_pid(). Aborting.
Feb 26 17:46:57 bibr001 systemd: Caught , cannot fork for core
dump: Cannot allocate memory
Feb 26 17:46:57 bibr systemd: Freezing execution.
Feb 26 17:47:22 bibr dbus[768]: [system] Failed to activate service
'org.freedesktop.systemd1': timed out
Feb 26 17:47:22 bibr dbus-daemon: dbus[768]: [system] Failed to activate
service 'org.freedesktop.systemd1': timed out
Feb 26 17:47:22 bibr systemd-logind: Failed to start session scope
session-2223342.scope: Activation of org.freedesktop.systemd1 timed out
org.freedesktop.DBus.Error.TimedOut
Feb 26 17:47:47 bibr dbus[768]: [system] Failed to activate service
'org.freedesktop.systemd1': timed out
Feb 26 17:47:47 bibr systemd-logind: Failed to abandon session scope:
Connection timed out
Feb 26 17:47:47 bibr dbus-daemon: dbus[768]: [system] Failed to activate
service 'org.freedesktop.systemd1': timed out

And after the systemd: Freezing execution. systemctl is no longer able
to communicate with systemd. It has all the looks of a memory leak
somewhere (systemd  (-logind) or telnetd) but how can I debug this...

Pascal Kolijn

Vrije Universiteit - Amsterdam
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Viktor Mihajlovski]

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,

 with systemd > v229 all virtio block devices will receive persistent
 device names in the format /dev/disk-by/virtio-pci-, the
 last component being the udev built-in path_id.

 This naming introduces some issues.

 First and obvious, there are virtio implementations not based
 on PCI, like virtio-ccw (currently only on s390) and virtio-mmio
 (for which I can't speak). This results in persistent names like
 /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id.
 One seemingly obvious remedy would be to make the path_id return
 virtio-ccw- or more generally virtio--,
 both easily done with small patches to systemd-udev.

 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 with other (non-virtio) devices. The naming otoh
 suggests that virtio-pci is a subsystem of its own, which is simply
 incorrect from a by-path perspective.
>>>
>>> From the ccw perspective, this is quite similar: The virtio proxy
>>> device shows up on the ccw bus, just like e.g. a dasd device shows up
>>> on the ccw bus.
>>>

 Using just the plain PCI path id is actually sufficient to identify
 a virtio disk by its path. This would be in line with virtio
 network interface path names which use the plain PCI naming.
>>>
>>> Same for ccw: The id on the ccw bus (devno) is already unique and
>>> persistent.
>>>

 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 time now to settle on a common approach for all
 virtio types.

 For the reasons above, I'd vote for -, which
 would work for PCI and CCW, not sure about ARM MMIO though.
 Opinions?
>>>
>>> I'm not sure whether there is any reason to make virtio special,
>>> although this depends upon what virtio-mmio looks like in the Linux
>>> device model (any arm folks here?)
>>>
>>> In the end, I'd be happy with any naming scheme that does not include
>>> 'pci' for non-pci devices.
>>>
>> Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407
>> that introduced this behavior: can you comment on the reasoning for
>> prepending virtio- to the bus, i.e. why would pci- not
>> sufficiently identify the device?
> 
> As with many things, it looked like a good idea at the time. In commit
> message I referenced discussion on upstream mailing list. In that
> thread we got reassured that there is one-to-one correspondence
> between virtio and pci devices. IIRC, we had bugs for RHEL and CentOS
> 7 were users requested these symlinks. Hence we went ahead with above
> naming scheme.
> 
> Your argument about virtio being first component of the path makes
> sense to me, but then again, we wanted to distinguish these devices
> (because of user demands).
> 
> In retrospect what we did wasn't probably the best we could.
> Nevertheless, I'd not change the naming. After all, these symlinks are
> for users and since then I didn't hear complains about them. I'd only
> adjust the code so that we produce correctly named symlinks for
> different parent buses (pci, ccw, mmio). IOW we would remove hardcoded
> "pci" string.
Thanks for taking the time to explain the background. As it happens, I
have a local patch to produce virtio-- symlinks as
you suggested. However, I wasn't really happy about that for two reasons:

1. The s390x architecture has native disks that show up as devices on
the bus, so it is possible to create persistent symlinks based solely on
the bus id, irrespective of the disk type (virtio or dasd). This helps
in defining OS images that can run on native and paravirtualized disk
setups. Which is broken now.

This might be considered an architecture one-off, but

2. SCSI disk pathids are generally represented as -
(the lun in hba specific notation). For a generic/parallel SCSI HBA the
path id will always be in a format like
 pci-:00:03.0-scsi-0:0:0:0
except for the virtio HBA, which would look like this
 virtio-pci-:00:03.0-scsi-0:0:0:0
This makes even less sense to me (even if there are probably no more
generic SCSI adapters to be found in the wild).

My fear is that by dodging a potential inconvenience for the users much
more pain will arise further down the road whenever a new virtio device
type shows up. My take would rather be to produce semantically correct
builtin path ids and have the distributions add their custom rules for
virtio-blk if they are wanted.
> 
> Michal
>>
>> --
>>
>> Mit freundlichen Grüßen/Kind