Re: [systemd-devel] systemd-udevd -any way to list triggered rules with their files etc ?
On Mo, 03.10.22 02:17, Branko (bran...@avtomatika.com) wrote:
> cat /etc/udev/rules.d/99-zz-network.rules:
> ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:22:33:44:55:66",
> NAME="wlan17", OWNER="chosen_user", GROUP="chosen_group",
> MODE="0666"
ACTION="add" is almost always the wrong expression. Because devices
will be triggered via "change" and similar, and thus your props will
be dropped again once that happens.
You want ACTION!="remove" instead, i.e. match all "positive" events,
i.e. where the device is still there afterwards (which is
systematically different from "remove" where it isn't).
> I know it does get triggered, since after replugging the WIFi stick I
> do get "wlan17" interface.But resulting created device in
> /dev/bus/usb/00x/00y gets created with MODE=0640 and root:usb
As mentioned elsewhere, what's a usbfs file, not a netif. network
interfaces have no ownership concept.
> I'm at a loss here. How is one supposed to get more detailed info on
> what's and WHY is going on with systemd-udevd tree processing ?
if you boot up with "debug" you should get tons of debug output to
wade through.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] Attaching virtual session (e.g. SSH) to seat
On Sa, 01.10.22 15:46, Nils Kattenbeck (nilskem...@gmail.com) wrote: > I am logging in on a PC using SSH and need to access some peripherals > which are attached to seat0. > loginctl shows that my session is not attached to any seat: > > SESSION UID USER SEAT TTY > 50 1000 septatrix pts/0 > > The devices are added to the seat using udev rules > and I explicitly want to avoid making the device world read-/writeable > or adding it to a group. > Reading through the man pages for systemd-logind, pam_systemd etc > did not lead me anywhere helpful but only confirmed the fact > that virtual sessions are not assigned any seat by default. > However I was unable to find information on how it is determined > if a session is "virtual" or whether it can be configured for > pam/logind/udev... So in logind "seat" is a way to group hw, and that hw-bound sessions hence associate with one of these "seat"s. Non-hw-bound sessions don't. It's how this was designed. There's simply no way to say "hey, I am non-hw-bound session with a seat", and I am not convinced the usecase is convincing enough to add such a concept. So, you might get quite far via setting XDG_SEAT env var in the PAM session, but it's really a mess, I am pretty sure this will not work properly, because it's not designed like that. i.e. multiple sessions on the same seat are supposed to be session switchable, i.e. one in the fg and all others in the bg, but any of them could be put in the fg any time. but that simply makes no conceptual sense if an SSH session is in the mix. Sorry if that's disappointing. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-repart help requested please
On Mo, 03.10.22 22:04, bl...@baaa.sh bl...@baaa.sh (bl...@baaa.sh) wrote: > Greetings to you all, > > I read through this > https://0pointer.net/blog/fitting-everything-together.html, several > times and was inspired to try build this > https://0pointer.net/blog/images/partitions.svg, as an exercise to > help me learn. > > I've got this https://gitlab.com/baaash/aio/-/blob/main/aio.org so > far. (probably worthy of a chuckle for some, but we all start > somewhere right?) > > anyways, when I do a: > > sudo mkosi > > the image builds fine. cool. > > when i boot into with systemd-nspawn I see no such growing of > partitions, and furthermore am prompted to enter a new root > password. systemd-nspawn will boot the image for you. It will mount the file systems in the image first, and it will issue the fsgrow ioctls on the mounted file systems if that's requested in the GPT partition flags. But it will *not* grow the partitions, that's what systemd-repart can do for you. You may use the "--image=" switch to invoke it directly on the disk image. You can also specify "--size=" to grow the image file on disk first. (this will work only if you have some suitable /usr/lib/repart.d/ drop-ins in place that tell repart what to actually grow) So, if you build an image with mkosi, you could then grow/complete it with systemd-repart, and then boot it up with nspawn, and things should just work. > The password thing I assume is because I need to remove the > reference in mkosi, and pass this to systemd-nspawn, as described in > the systemd.firstboot man page...[edit:confirmed], But the repart > thing has me stumped. you can either provision a root pw: 1. in mkosi via the mkosi.rootpw file 2. at first boot by padding in a credential via nspawn's new --set-credential=passwd.hashed-password.root:… switch 3. at first boot interactively via systemd-firstboot. the systemd-firstboot stuff is done only on first boot, and if no root pw has been configured yet. First boot is defined by whether /etc/machine-id being initialized or not. Recent mkosi versions will ensure that file is reset properly ensure this works. (in fact, for now I'd recommend working with git versions of mkosi) > Asking in IRC it was pointed out systemd-repart should just work > automatically provided the partition info was sitting in > /usr/lib/repart.d directory, but that it needs no MachineID set in > order to qualify as "first.boot". Correct. > I don't have one set but one is being created in the process. I'm > missing a piece to this puzzle. > > my eyes burn, my head hurts, and i'm no closer to understanding > this, so i wondered if anyone on the list can succinctly explain > this to me or perhaps provide a link to a basic working example i > can try get my head around; provided of course, someone has already > undertaken this exercise on their own, and wouldn't mind sharing. Happy to help! We should probably open a group chat somewhere for people who want to build images like that. Since I am usually at home in Signal for things like that, maybe we should open a chat room there for that? (nah, not an IRC fan, not gonna return there, sorry) Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] prevent systemd-journald rotating message
On Do, 06.10.22 10:10, d tbsky (tbs...@gmail.com) wrote: > Hi: > when I type "dmesg" I saw it is fulled by systemd-journald > rotating message like below. is there parameter to prevent the > rotating warning? > > [708993.589762] systemd-journald[515]: Data hash table of > /run/log/journal/93f434f608654cf990b2e70c656dfacd/system.journal has a > fill level at 75.1 (3283 of 4373 items, 2519040 file size, 767 bytes > per hash table item), suggesting rotation. > [708993.590947] systemd-journald[515]: > /run/log/journal/93f434f608654cf990b2e70c656dfacd/system.journal: > Journal header limits reached or header out-of-date, rotating. No, we have no concept of turning off individual log messages. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?
On Fr, 07.10.22 07:24, Klaus Ebbe Grue (g...@di.ku.dk) wrote: > Hi systemd-devel, > > I have a user question which I take the liberty to send here since > "about systemd-devel" says "... it's also OK to direct user > questions to this mailing list ...". > > I have a daemon, /usr/bin/mydaemon, which listens on one and only > one TCP port, say , and which does no more than communicating > over and creating, reading, writing and deleting files in > /home/me/mydaemon/. > > Mydaemon leaves it to systemd to create a socket which listens at > . > > It is unimportant whether or not mydaemon is started at boot and it > is also unimportant whether or not mydaemon is socket activated. As > long as it is at least one of the two. > > Now I want to upgrade mydaemon to a new version using a script, > without race conditions and without closing the listening socket. I > want the listening socket to stay open since otherwise there can be > a one minute interval during which it is impossible to reopen . > > If it is just a clean upgrade, the script could replace > /usr/bin/mydaemon, then stop mydaemon. If the daemon is socket > activated there is no more to do. If the daemon is activated only on > boot then the script must end up restarting mydaemon. > > But now I want to do some more while mydaemon is not running. It > could be that my script should take a backup of /home/me/mydaemon/ > in case things go wrong. It could be the script should translate > some file in /home/me/mydaemon/ to some new format required by the > new mydaemon or whatever. > > So I need to stop mydaemon in such a way that mydaemon cannot wake > up while my script fiddles with /home/me/mydaemon/. > > According to https://0pointer.de/blog/projects/three-levels-of-off > it seems that that was possible in 2011: just do "systemctl disable > mydaemon.service". But when I try that, mydaemon still wakes up if I > connect to using eg netcat. Well, that's a misunderstanding... > I have also tried to mask mydaemon. But if I then connect to > using netcat, then netcat gets kicked of. And if I try again then > is no longer listening. > > QUESTION: Is it possible to let systemd create a listening socket > and yet be able to have that socket activate nothing, at least > temporarily? Can't you run your upgrade script in idempotent way as a helper service that is pulled in by your main daemon and ordered before it, but conditions itself out if it already did its job? that's usually the most robust way, since then it's sufficient to just restart your daemon or reboot, and everything will always catch up correctly. i.e. if you have foo-daemon.socket + foo-daemon.service then define foo-upgrade.service that is pulled in from foo-daemon.service via `Wants=foo-upgrade.service` + `After=foo-upgrade.service`. And then add `ConditionFileExists=!/some/touch/file` to `foo-upgrade.service` to make it a NOP if things have already been updated, using a touch file. (some better, smarter condition check might work as well, see man pages of things systemd can check for you). Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
After experimenting some more, I can see that if there's no [Install] section and the unit is enabled by putting it into /usr/lib/systemd/*/*.target.wants, then is-enabled is static, and `systemctl enable` does nothing and explains the situation. Which makes me think that one should either add the [Install] section, or enable a unit via /usr/lib/systemd/*/*.target.wants. If both are done, is-enabled is disabled, and one can enable it twice (provide a second route). Which probably is not particularly bad, but is confusing. On Tue, Sep 20, 2022 at 11:23 AM Andrei Borzenkov wrote: > > On Tue, Sep 20, 2022 at 10:42 AM Barry wrote: > > > > Enabled does mean that it will or will not run. > > It means that it is wanted by the default target. > > > > No. It means that it is wanted by whatever units are listed in > [Install] section (actually, it is "enabled" even if only aliases are > created, so more correct is - it is enabled if links mentioned in > [Install] section are created).
Re: [systemd-devel] Setting up a VPN daemon as a Portable Service
On Mon, 10 Oct 2022 at 04:00, Duncan Gibson wrote: > > Final update, hopefully. Here's a gist with a script, service unit, and > readme. Again, that is not safe and it will fail at some point as it is open to race conditions. You have to use ExtensionImages= instead. > On Sun, Oct 9, 2022 at 11:10 AM Duncan Gibson wrote: >> >> After doing some more looking, it seems like the /etc folder is overlaid >> with /var/lib/overlays/etc/upper, meaning that changes to /etc/ get saved in >> the overlay, which should survive updates. I've added the service definition >> there and the binaries to my home directory (and updated the service >> definition to point there), and it seems to just work. I might look into >> putting the binaries in a system extension, and update the service >> definition to require the extension be running, but it seems to work as-is. >> Time to wait for the next system update and see if it breaks. >> >> On Sat, Oct 8, 2022 at 2:02 PM Luca Boccassi wrote: >>> >>> On Sat, 8 Oct 2022 at 18:51, Duncan Gibson wrote: >>> > >>> > Hm. Actually, no, I don't think it will. Services installed the normal >>> > way won't survive the A/B update system. >>> >>> I don't know what that is and how it works. >>> >>> > On Sat, Oct 8, 2022 at 12:23 PM Duncan Gibson >>> > wrote: >>> >> >>> >> Oh, now that's a new way of doing it. I'll definitely give that a shot. >>> >> That sounds like it has the best chance of working. >>> >> >>> >> On Sat, Oct 8, 2022 at 12:20 PM Luca Boccassi wrote: >>> >>> >>> >>> On Sat, 2022-10-08 at 11:13 -0400, Duncan Gibson wrote: >>> >>> > The problem wasn't mounting the system extension automatically. That >>> >>> > worked >>> >>> > just fine. It was that systemd would try to start the service before >>> >>> > the >>> >>> > system extension mounted, which would fail, for obvious reasons. This >>> >>> > weekend I think I'm going to try the BindReadOnlyPaths option and see >>> >>> > if I >>> >>> > can get that to work. >>> >>> >>> >>> Don't do that. system-wide extensions are not supposed to add units, >>> >>> and it will not work. Portable services are for distributors - for >>> >>> locally built extensions, you can simply use a normal service with >>> >>> ExtensionImages= that points to your extension, and it will be >>> >>> overlayed with the rootfs. >>> >>> >>> >>> > On Fri, Oct 7, 2022 at 3:35 PM David Anderson >>> >>> > wrote: >>> >>> > >>> >>> > > Yeah, so far we (tailscale) haven't found a good way to run on the >>> >>> > > Steam >>> >>> > > Deck at bootup, and also survive the A/B OS updates. Systemd system >>> >>> > > extensions _can_ be activated during bootup, if you place the >>> >>> > > extension in >>> >>> > > one of the well-known locations (/var/lib/extensions would be the >>> >>> > > one to >>> >>> > > use on Deck, as iirc it survives A/B upgrades), and the systemd- >>> >>> > > sysext >>> >>> > > service is enabled. >>> >>> > > >>> >>> > > I would check if systemd-sysext.service is enabled on the deck, and >>> >>> > > if >>> >>> > > not, file a request with Valve to enable that service in a future >>> >>> > > update. >>> >>> > > You should present it as enabling further customization of their >>> >>> > > platform. >>> >>> > > >>> >>> > > Another possible reason that sysexts aren't working for you, is >>> >>> > > that the >>> >>> > > Deck's /etc/os-release doesn't define a SYSEXT_LEVEL, and the >>> >>> > > VERSION_ID >>> >>> > > changes with every OS update. Because of this, the system extension >>> >>> > > will >>> >>> > > refuse to activate after every update (either SYSEXT_LEVEL or >>> >>> > > VERSION_ID >>> >>> > > must match exactly), until you rebuild a new image with the right >>> >>> > > OS >>> >>> > > metadata. Asking Valve to set SYSEXT_LEVEL to a stable value would >>> >>> > > make it >>> >>> > > even easier to provide Deck OS extensions reliably :) >>> >>> > > >>> >>> > > - Dave >>> >>> > > >>> >>> > > On Thu, Oct 6, 2022, at 12:08, Arian van Putten wrote: >>> >>> > > >>> >>> > > Afaik Portable services run in an isolated root and dont have >>> >>> > > access to >>> >>> > > the hosts rootfs. You'd have go include iptables and all its >>> >>> > > dependencies >>> >>> > > in the portable services directory. If you don't want to do that >>> >>> > > you'd have >>> >>> > > to use BindReadOnlyPaths= to give the service access to the >>> >>> > > required host >>> >>> > > paths or you'd have to use a system extension. >>> >>> > > >>> >>> > > That's probably why they advice running as a system extension. >>> >>> > > >>> >>> > > I think there are mechanisms for setting up system extensions on >>> >>> > > startup >>> >>> > > but I'm not familiar enough with the details. Maybe someone else in >>> >>> > > the >>> >>> > > list knows. >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > On Thu, 6 Oct 2022, 20:21 Duncan Gibson, >>> >>> > > wrote: >>> >>> > > >>> >>> > > Hi, everyone. >>> >>> > > >>> >>> > > The high-level overview: I'm trying to i
