Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text
I made some progress... I modified the script to start the container like this:
exec ${CARCH:+setarch "$CARCH"} systemd-nspawn -q \
-D "$working_dir" \
-E "PATH=/usr/local/sbin:/usr/local/bin:/usr/bin" \
--register=yes --as-pid2 --machine=test \
"${mount_args[@]}" \
"$@"
Now when the script is called, machinectl can see the container, but I
cannot connect to it:
# systemd-run --pipe -M test /usr/bin/distccmon-text
Failed to create bus connection: Protocol error
# machinectl
MACHINE CLASS SERVICEOS VERSION ADDRESSES
test container systemd-nspawn arch - -
1 machines listed.
On Tue, Nov 19, 2019 at 4:14 AM Lennart Poettering
wrote:
>
> On Fr, 15.11.19 17:17, John (gray...@archlinux.us) wrote:
>
> > The container is created by one of the Arch Linux build scripts
> > (https://git.archlinux.org/devtools.git/tree/arch-nspawn.in). I do
> > not believe it runs with its own systemd/dbus. When I am compiling
> > (https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the
> > container, is there a way I can run distccmon-text from within the
> > same container to get it to read the same PID values?
>
> No this doesn't work. PID namespacing is kinda at the core of what a
> container is, making them match in the host and container's view isn't
> really feasible.
>
> (You should be able to run your distcc tool inside the container
> though, with systemd-run --pipe -M …)
>
> Sorry!
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text
Thank you for the reply. I believe the container is being invoked from
a user session. I am unclear how to set the containername. The Arch
tools are invoking systemd-nspawn like this:
exec ${CARCH:+setarch "$CARCH"} systemd-nspawn -q \
-D "$working_dir" \
-E "PATH=/usr/local/sbin:/usr/local/bin:/usr/bin" \
--register=no --keep-unit --as-pid2 \
"${mount_args[@]}" \
"$@"
I tried appending a -M name into that mix but got these errors. Can
you recommend a workaround for either the script or the systemd-run
command?
"--keep-unit --register=yes may not be used when invoked from a user session."
On Tue, Nov 19, 2019 at 4:14 AM Lennart Poettering
wrote:
>
> On Fr, 15.11.19 17:17, John (gray...@archlinux.us) wrote:
>
> > The container is created by one of the Arch Linux build scripts
> > (https://git.archlinux.org/devtools.git/tree/arch-nspawn.in). I do
> > not believe it runs with its own systemd/dbus. When I am compiling
> > (https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the
> > container, is there a way I can run distccmon-text from within the
> > same container to get it to read the same PID values?
>
> No this doesn't work. PID namespacing is kinda at the core of what a
> container is, making them match in the host and container's view isn't
> really feasible.
>
> (You should be able to run your distcc tool inside the container
> though, with systemd-run --pipe -M …)
>
> Sorry!
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Send SFP event from kernel driver to user space (UDEV)
On 11/19/2019 01:19, Andrew Lunn wrote: > On Mon, Nov 18, 2019 at 11:54:31AM +, Shay Drory wrote: >> On 11/18/2019 03:29, Andrew Lunn wrote: >>> On Sun, Nov 17, 2019 at 11:46:15AM +, Shay Drory wrote: >>> >>> Hi Shay >>> >>> It would be good to Cc: the generic SFP code maintainers. >> The suggested solution is not targeted for SFP drivers (see below), >> but I added them to the Cc list. > Hi Shay > > So you are proposing something which won't work for the generic SFP > code? That should be an automatic NACK. Whatever you propose needs to > be generic so that it can work for any NICs that do firmware support > for SFPs, and those who let Linux handle the SFP. The suggestion is targeted to support all types of NICs that do firmware support for SFPs. But I want to do it via the ethtool-nl interface and not by using phy drivers. > >> The feature is targeted to netdev users. It is expected from the >> user to query current state via ethtool -m and afterwards monitor >> for changes over UDEV. > What exactly are you interested in? What are your use cases. When > hwmon devices are created, you should get udev events. Maybe that is > sufficient? Or are you interested in some other parts of the SFP than > the diagnostic sensors? It looks like the hwmon is not sufficient for out purpose. I am interesting in getting events when the SFP is inserted or removed. > >>> Would you add just SFP insert/eject to UDEV. Or all the events which >>> get sent via netlink? Link up/down, route add/remove, etc? >> It makes sense to notify all events. What do you think? > I don't particularly like two ways to get the same information. It > means we have two APIs we need to maintain forever, when just one > should be sufficient. > >>> Is UDEV name space aware? Do you run a udev daemon in each network >>> name space? I assume when you open a netlink socket, it is for just >>> the current network namespace? >> UDEV will follow netlink name-space. > So you do plan to have a udev daemon running in every network name > space. Does udev even support that? > > I'm sceptical using udev is a good idea. But having netlink events > does sounds reasonable. And if you are willing to wait a while, > ethtool-nl does seem like a good fit. But please make sure your > solution is generic. > >Andrew Thanks for your comments. The using of Udev is under internal discussion. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about storing unit/job statistics
On Fr, 08.11.19 11:15, Philip Withnall (phi...@tecnocode.co.uk) wrote: > Hello all, > > As part of work on a GNOME feature for monitoring how often the user > uses applications (for example, to let them know that they spent 4 > hours in the Slack app, or 17 hours playing games), I’m trying to work > out the best way to store data like that. > > If we assume the system is using systemd user sessions, then an > application being run is actually a unit being started, and so the data > we want to store is actually the duration of each unit run. > > A related issue is that of storing network usage data per unit, to > allow the user to see which apps have been using the most data over the > last (say) month. This data can already be tracked by systemd for you, just set IPAccounting=yes for the service. Alas this only works for system services currently, since the bpf/cgroup2 logic this relies on is only accessible to privileged processes. (Fixing that would probably mean introducing a tiny privileged service that takes a cgroup fd as input, and then installs the correct bpf program and bpf table into it, returning the fds for these to objects. Happy to take a patch for that.) > If I were to implement this as a separate daemon, it would need to be > active all the time, listening to UnitNew/UnitRemoved/JobNew/JobRemoved > signals from systemd. That seems like a waste of a process. Let’s call > this problem 0. This data is already collected and written to the journal anyway if you turn on the various XYZAccounting= properties for your services. Then use the invocation ID of the service and the MESSAGE_ID=ae8f7b866b0347b9af31fe1c80b127c0 match in journalctl to find these. > One approach would be to store this data in the journal, but (problems > 1-3): > 1. We can’t control how long the journal data is around for, or even > if it’s set to persist. You can pull the data from the journal at your own pace, always keeping the cursor you last read from around so that you don't lose messages. > 2. This data couldn’t be stored separately (for example, in a separate > journal file) so that the user could delete it all together and > separately from the rest of the journal. (To reset their usage data.) > 3. Querying it from the journal would mean filtering and iterating > through everything else in the journal, which is not going to be the > fastest (although it probably wouldn’t be too bad, and we would be > appending a lot more often than we would be querying). Well, the format is indexed. It shouldn't be that bad. > So I have two questions: > 1. Does this seem like the kind of functionality which should go into > the journal, if it was modified to address problems 1-3 above? > 1a. If not, do you have any suggestions for how to implement it so > that problem 0 above is not an issue, i.e. we don’t have to keep a > daemon running all the time just to record a small chunk of data once > every few minutes? > 2. Does this seem like a subset of a larger bit of functionality, > storing metrics about units and jobs for later analysis, which might be > interesting to non-desktop users of systemd? A long-standing TODO item in systemd was to have some form of metrics collector, that may be turned on and that writes a time-keyed ring buffer of metrics collected per service to disk, from the data collected via cgroup attributes, bpf and so on. But so far noone has found the time to do it. It probably should be decoupled from PID 1 in some form, so that PID 1 only pings it whenever a new cgroup shall be watched but the collecting/writing of the data points is done entirely separate from it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text
On Fr, 15.11.19 17:17, John (gray...@archlinux.us) wrote: > The container is created by one of the Arch Linux build scripts > (https://git.archlinux.org/devtools.git/tree/arch-nspawn.in). I do > not believe it runs with its own systemd/dbus. When I am compiling > (https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the > container, is there a way I can run distccmon-text from within the > same container to get it to read the same PID values? No this doesn't work. PID namespacing is kinda at the core of what a container is, making them match in the host and container's view isn't really feasible. (You should be able to run your distcc tool inside the container though, with systemd-run --pipe -M …) Sorry! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
