Re: [systemd-devel] cannot unsubscribe from this list
W dniu 16.10.2019 o 16:26, Brian Reichert pisze: > On Wed, Oct 16, 2019 at 07:43:10AM +, Zbigniew J??drzejewski-Szmek wrote: >> On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote: >>> I initiated an unsubscribe from this web page: >>> >>> https://lists.freedesktop.org/mailman/options/systemd-devel >>> >>> That created a confirmation email, that I replied to. >> >> Yeah, that doesn't work. Use the web interface: >>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > I just tried that second web interface. > > The resulting confirmation email aLso bounces: > > : >131.252.210.177 does not like recipient. > Remote host said: 550 5.1.1 : > Recipient address rejected: User unknown in local recipient table > Giving up on 131.252.210.177. > > I can provide email headers, SMTP logs, etc., for either failing > use case, if anyone thinks that would help. See the contents of the confirmation email. You can confirm by replying (that doesn't work as you stated), but there should be also a link that allows you to confirm on a webpage. You can use it without problems, probably > >> Zbyszek > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cannot unsubscribe from this list
On Wed, Oct 16, 2019 at 07:43:10AM +, Zbigniew J??drzejewski-Szmek wrote: > On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote: > > I initiated an unsubscribe from this web page: > > > > https://lists.freedesktop.org/mailman/options/systemd-devel > > > > That created a confirmation email, that I replied to. > > Yeah, that doesn't work. Use the web interface: > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel I just tried that second web interface. The resulting confirmation email aLso bounces: : 131.252.210.177 does not like recipient. Remote host said: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table Giving up on 131.252.210.177. I can provide email headers, SMTP logs, etc., for either failing use case, if anyone thinks that would help. > Zbyszek -- Brian Reichert BSD admin/developer at large ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services
* flock leaves the lock file behind so you'd need some type of cleanup in case you really want the jobs to be trace-free. This is not as trivial is it might seem, e.g. you cannot do it from the service units themselves in `ExecStartPost=` or similar. An ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \ /usr/bin/rm /path/to/lock.file should solve this issue. So you can remove a file other processes are blocked lock-waiting on? Didn't expect this to work, thanks for the hint. It's a common misconception (especially when grown up with Windows) that "rm" removes a file: Actually it "unlinks" the name from the inode. As long as the inode is opened by the kernel, the file (as seen from the kernel's perspective) still exists. I haven't really grown up with Windows ;P Assuming `flock` (the binary) uses the flock() syscall it still needs to go through VFS to get a file descriptor. So if a second process calls `flock` after the first one has already unlinked the name from the inode, the lock file will not be found and thus be re-created, breaking the locking mechanism. Or did I miss something and the second flock somehow obtains the inode number of the old lock? Best regards, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: how to debug kernel panic which generated by udevadm at systemd?
Dear Mantas and Ulrich, Thank you very much for your help. Because systemd will automatically call this driver, which causes the system to fail to start normally, I have to load the driver in a different way (load it separately), and then debug it. Thanks again for your help. thanks, Byron At 2019-10-16 14:12:35, "Ulrich Windl" wrote: Mantas Mikulenas schrieb am 15.10.2019 um 20:32 in >Nachricht >: >> On Tue, Oct 15, 2019 at 3:02 PM www wrote: >> >>> Dear all, >>> >>> I add a new driver to kernel, and it probe success. When enter into >>> systemd, the udevadm generate a kernel panic. >>> I want to ask how to debug it and find out where the error occurred? When >>> did udevadm load? What commands are used by udevadm, and what are the >>> specific operations? >>> >> >> There aren't many udevadm calls in systemd... The main one is >> systemd-udev-trigger.service, which calls `udevadm trigger >> --type=subsystems --action=add`, then repeats the same for type=devices. It >> tries to generate coldplug uevents by writing 'add' to each found device's >> /sys/.../uevent file. > >That's waht I guessed: The driver being loaded created siome udev event (with >probably invalid data in it), so when processing those, problems are >triggered. > >I'm not arguing whether all thge components involved are robust enough (to >avoid a kernel panic), but is there a kind of "driver validation tool" (like >inserting the module, querying it's metedata, udev events, removing the module >again, etc.)? > > >Regards, >Ulrich > >> >> (The second is systemd-udev-settle.service, but it is disabled by default >> on most systems and just waits for udev's job queue to empty.) >> >> -- >> Mantas Mikulėnas > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: cannot unsubscribe from this list
>>> Zbigniew Jedrzejewski-Szmek schrieb am 16.10.2019 um >>> 09:43 in Nachricht <20191016074310.gp17...@in.waw.pl>: > On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote: >> I initiated an unsubscribe from this web page: >> >> https://lists.freedesktop.org/mailman/options/systemd-devel >> >> That created a confirmation email, that I replied to. > > Yeah, that doesn't work. Use the web interface: >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel Glad to get the messages as mail at least ;-) > > Zbyszek > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services
>>> Alexander Koch schrieb am 15.10.2019 um 21:48 in Nachricht <39b05185c3bdf699f7f00c23e0a4a...@alexanderkoch.net>: >> > * flock leaves the lock file behind so you'd need some type of >>> cleanup in case you really want the jobs to be trace-free. This is >>> not as trivial is it might seem, e.g. you cannot do it from the >>> service units themselves in `ExecStartPost=` or similar. >> An >> >> ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \ >> /usr/bin/rm /path/to/lock.file >> >> should solve this issue. > > So you can remove a file other processes are blocked lock-waiting on? > Didn't > expect this to work, thanks for the hint. It's a common misconception (especially when grown up with Windows) that "rm" removes a file: Actually it "unlinks" the name from the inode. As long as the inode is opened by the kernel, the file (as seen from the kernel's perspective) still exists. > >> If your units are actually dependent on each other, than maybe you >> should think about your approach in general. But to be able to help you >> with that we need more information about the actual dependencies of the >> applications started by your units and at which interval they shall >> run. > > Okay I guess I should come up with the actual scenario, here we go: > > On my Arch Linux workstation I've got three .timer triggered .service > units > that do package manager housekeeping (I don't know if you're familiar > with > Arch/Pacman so I'll annotate their purposes): > > 1) Synchronize package database (equivalent of `apt-get update` on > Debian) > > [Timer] > OnCalendar=8-17/2:00 > Persistent=true > > [Service] > ExecStart=/usr/bin/pacman -Syq > > 2) Update file database (equivalent of `apt-file update`) > > [Timer] > OnCalendar=weekly > Persistent=true > > [Service] > ExecStart=/usr/bin/pacman -Fyq > > 3) Purge old packages from cache (something like `apt-get autoclean`) > > [Timer] > OnCalendar=daily > Persistent=true > > [Service] > ExecStart=/bin/sh -c 'paccache -r -k 2; paccache -r -k 0 -u' > > As you can see, I'd like to have different execution intervals for all > of > these tasks so I'd like to keep them as separate services (which also > seems > the intuitive approach to me). > > I must admit that I haven't tried, but I'm pretty sure that at least 1 > and > 2 do lock the ALPM database so if you try to issue one of these Pacman > calls > while the other is running it will fail, complaining about a lock file > being > present. > > My current workaround for this is using `RandomizedDelaySec=15m` in > conjunction with `AccuracySec=1` in the .timer units to spread the > triggers. > > While this does work I'm really curious about the 'proper' way of > modeling > this. Is it such an academic problem to have the need of ensuring that > two > timers (or services) don't fire simultaneously? I had thought this to be > really simple with such an elaborate service manager like systemd, with > all > its graph theory power and the-like. > > (If I were a heretic I'd say 'We can do DNS, DHCP and NTP with systemd > without any third party software but we need additional utilities to > ensure > that two things don't happen at the same time??' ;) ) > > I think there are plenty of other scenarios, e.g. ideally I'd like my > backup > service not to kick in while btrfs-scrub@home.service is running... or > maybe > it's just me seeing this need ;) > > > Best regards, > > Alex > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cannot unsubscribe from this list
On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote: > I initiated an unsubscribe from this web page: > > https://lists.freedesktop.org/mailman/options/systemd-devel > > That created a confirmation email, that I replied to. Yeah, that doesn't work. Use the web interface: > https://lists.freedesktop.org/mailman/listinfo/systemd-devel Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: how to debug kernel panic which generated by udevadm at systemd?
>>> Mantas Mikulenas schrieb am 15.10.2019 um 20:32 in Nachricht : > On Tue, Oct 15, 2019 at 3:02 PM www wrote: > >> Dear all, >> >> I add a new driver to kernel, and it probe success. When enter into >> systemd, the udevadm generate a kernel panic. >> I want to ask how to debug it and find out where the error occurred? When >> did udevadm load? What commands are used by udevadm, and what are the >> specific operations? >> > > There aren't many udevadm calls in systemd... The main one is > systemd-udev-trigger.service, which calls `udevadm trigger > --type=subsystems --action=add`, then repeats the same for type=devices. It > tries to generate coldplug uevents by writing 'add' to each found device's > /sys/.../uevent file. That's waht I guessed: The driver being loaded created siome udev event (with probably invalid data in it), so when processing those, problems are triggered. I'm not arguing whether all thge components involved are robust enough (to avoid a kernel panic), but is there a kind of "driver validation tool" (like inserting the module, querying it's metedata, udev events, removing the module again, etc.)? Regards, Ulrich > > (The second is systemd-udev-settle.service, but it is disabled by default > on most systems and just waits for udev's job queue to empty.) > > -- > Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
