| View previous topic :: View next topic |
| Author |
Message |
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
 Posted: Sun Oct 17, 2021 6:29 pm Post subject: |
 |
|
I align with the people who think the coding practice is self-serving. I don't mind labeling it malicious, except these particular coders fancy themselves as do-gooders. Their goal is more adoption of their code. Attempts at persuasion generally futile.
This sort of tension is part of the scene. As long as I can navigate around it, I just do and leave it at that.
I have a couple scripts with opening parts that direct to this behavior or that, all depends on $0. I soft link the script to various filenames. In my case, the reason or point is that all the scripts operate to support the same (active firewall / firewall and log activity monitoring) function.
But yeah, having a daemon STARTING out of /lib is nutty. C'est la gare |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Sun Oct 17, 2021 7:34 pm Post subject: |
|
|
| Zucca wrote: | | I wonder what happens if you create a symlink to /sbin/udevd which points to /bin/udevadm..? |
Looks like it might work. Want to try and report? 
systemd-249/src/udev/udevadm.c
| Code: | static int run(int argc, char *argv[]) {
// ...
if (invoked_as(argv, "udevd"))
return run_udevd(argc, argv);
// ...
} |
systemd-249/src/basic/process-util.c
| Code: | bool invoked_as(char *argv[], const char *token) {
// ...
return strstr(last_path_component(argv[0]), token);
}
|
Nevertheless, if this happens to work for systemd-249, it might not for future versions.
| Hu wrote: | | Separately, I find it weird and wrong that there are any daemons running out of /lib/anything. |
It would not be strange for "internal binaries that are not intended to be executed directly by users or shell scripts", as the FHS puts it, but which are called by programs in /bin or /sbin. Binaries that would qualify for being in /usr/libexec otherwise, but for this special case being in /usr would be a packaging error (and considering that /usr/lib is tolerated as a replacement of /usr/libexec, and that /lib is the rootfs' counterpart of /usr/lib). But I do agree that it is a strange location for the udev daemon. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Sun Oct 17, 2021 7:44 pm Post subject: |
|
|
| Hu wrote: | | I find it weird and wrong that there are any daemons running out of /lib/anything. |
Same here. I always thought executables/scripts meant not to be run by any user, but another program/script should reside inside /usr/libexec.
And it seems my assumption was 50% correct if one follows FHS. | /usr/libexec/ purpose wrote: | 4.7. /usr/libexec : Binaries run by other programs (optional)
4.7.1. Purpose
/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.
Applications which use /usr/libexec in this way must not also use /usr/lib to store internal binaries, though they may use /usr/lib for the other purposes documented here.
Rationale
Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself. |
Underlined is the most important part.
So it is correct, but... strange, imho, to put executables under /lib.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
| Posted: Mon Oct 18, 2021 11:16 am Post subject: |
|
|
| udev became a part of systemd a long time ago. udev is going to assume presence of systemd. eudev doesn't assume presence of systemd. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Mon Oct 18, 2021 3:16 pm Post subject: |
|
|
| The code for udev was moved into the systemd project, yes. The systemd maintainers may, or may not, start adding systemd-specific dependencies to udev. They have had quite a bit of time to do that, and have not yet (to my knowledge) issued a udev release that, as packaged, is broken in the absence of systemd. (This is a bit interesting considering that there were several releases of GNOME that had a hard dependency on systemd.) Placing a udev symlink in a systemd directory is wrong in part because udev works without systemd. If udev had become a small component of systemd, unusable without it, it would make more sense to bury its implementation details in systemd-specific directories. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Mon Oct 18, 2021 3:20 pm Post subject: |
|
|
Hu,
Watch this space.
Keeping udev usable without the rest of systemd was one of the original reasons for founding the eudev project.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Mon Oct 18, 2021 4:23 pm Post subject: |
|
|
| I know, and I am aware that there is a case to be made that udev would have been more dependent by now if not for eudev. For today, I'm focusing on how the systemd-udevd project is making confusing packaging decisions and causing unnecessary breakage because users' expectations do not align with what upstream did. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Mon Oct 18, 2021 5:04 pm Post subject: |
|
|
To make thing a little more suspicious, there's no mention of udev in the list of programs systemd project maintains which can be run without systemd:This is probably why eudev is still alive.
EDIT: typo correction
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
Last edited by Zucca on Tue Oct 19, 2021 8:03 pm; edited 1 time in total |
|
| Back to top |
|
|
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
| Posted: Mon Oct 18, 2021 10:48 pm Post subject: |
|
|
If you want to be really free from systemd, you should migrate away from eudev, udev, systemd-tmpfiles, and other systemd components.
Otherwise, you will never get real separation of concern.
People on other linux distributions like artix experimented with smdev, mdev, nldev, ...
I'm also looking to remove dbus, too.
Retire eudev, and get an entirely different device manager. |
|
| Back to top |
|
|
Hund
Apprentice
Joined: 18 Jul 2016
Posts: 218
Location: Sweden
|
| Posted: Tue Oct 19, 2021 10:29 am Post subject: |
|
|
| crocket wrote: | If you want to be really free from systemd, you should migrate away from eudev, udev, systemd-tmpfiles, and other systemd components.
Otherwise, you will never get real separation of concern.
People on other linux distributions like artix experimented with smdev, mdev, nldev, ...
I'm also looking to remove dbus, too.
Retire eudev, and get an entirely different device manager. |
What options do a Gentoo user have if they don't want to use opentmpfiles? I just assumed it was the only option for us, because otherwise they would have used something else. Right?
Is it possible to avoid udev in the future if libinput depends on it? Or did I get that part wrong? I'm currently using evdev, but it looks like that has no future in Gentoo.
_________________
Collect memories, not things. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Tue Oct 19, 2021 3:12 pm Post subject: |
|
|
Currently, the responsible Gentoo maintainers have decided that using systemd-tmpfiles, which is a tmpfiles implementation copied from systemd, but not dependent on it, is the standard way for Gentoo systems to process tmpfiles configuration files. opentmpfiles was abandoned due to a security problem created by inappropriately expanding the use of tmpfiles past the original purpose. Fixing that was deemed harder than just copying the systemd-tmpfiles implementation, since that implementation is currently freestanding enough that it works properly on openrc-based systems.
Your options are:- Use systemd-tmpfiles
- Unmask the abandoned opentmpfiles
- Write your own tmpfiles processor
- Try to get by without a tmpfiles processor
If libinput develops a dependency on udev, then your options would be to accept the change, to revert that dependency, to replace udev with a udev-compatible fork that satisfied libinput, or to pin on an old libinput. Do you have evidence that libinput is planning such a dependency? Without knowing when or how such a dependency will occur, it is difficult to say which option users should take. For now, I recommend vigilance, but no action. |
|
| Back to top |
|
|
Hund
Apprentice
Joined: 18 Jul 2016
Posts: 218
Location: Sweden
|
| Posted: Tue Oct 19, 2021 5:14 pm Post subject: |
|
|
| Hu wrote: | Currently, the responsible Gentoo maintainers have decided that using systemd-tmpfiles, which is a tmpfiles implementation copied from systemd, but not dependent on it, is the standard way for Gentoo systems to process tmpfiles configuration files. opentmpfiles was abandoned due to a security problem created by inappropriately expanding the use of tmpfiles past the original purpose. Fixing that was deemed harder than just copying the systemd-tmpfiles implementation, since that implementation is currently freestanding enough that it works properly on openrc-based systems.
Your options are:- Use systemd-tmpfiles
- Unmask the abandoned opentmpfiles
- Write your own tmpfiles processor
- Try to get by without a tmpfiles processor
If libinput develops a dependency on udev, then your options would be to accept the change, to revert that dependency, to replace udev with a udev-compatible fork that satisfied libinput, or to pin on an old libinput. Do you have evidence that libinput is planning such a dependency? Without knowing when or how such a dependency will occur, it is difficult to say which option users should take. For now, I recommend vigilance, but no action. |
Why couldn't they use whatever Alpine Linux or port/adapt whatever {Open,Free}BSD is using? systemd-tmpfiles can't be the only option out there. :)
_________________
Collect memories, not things. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Oct 19, 2021 5:25 pm Post subject: |
|
|
| Hu wrote: | | Using exec -a, the shell can run one program, but claim some other name. |
exec -a is a bashism. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Tue Oct 19, 2021 7:40 pm Post subject: |
|
|
| Hu wrote: | Your options are:- Use systemd-tmpfiles
- Unmask the abandoned opentmpfiles
- Write your own tmpfiles processor
- Try to get by without a tmpfiles processor
|
I don't recall the details, but based on a thread here years ago I added virtual/tmpfiles to my package.provided, and have no issues at all without a tmpfiles processor. If I had to be honest, I'm not sure I understand what they actually do(?).
Tom |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Tue Oct 19, 2021 10:19 pm Post subject: |
|
|
If you run " <=sys-apps/openrc-0.17" from local overlay, you don't need sys-apps/opentmpfiles.
In any case: | Code: | ~ $ equery d virtual/tnpfiles
* These packages depend on virtual/tnpfiles: |
YMMV |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Wed Oct 20, 2021 1:56 am Post subject: |
|
|
| tld wrote: | | I added virtual/tmpfiles to my package.provided, and have no issues at all without a tmpfiles processor. If I had to be honest, I'm not sure I understand what they actually do(?). |
The idea behind tmpfiles is that certain directories contain state that is only useful while the system is up, and can be safely discarded at shutdown. From this idea, someone hit on using a tmpfs to implement the directory, which hints to the kernel that the data only needs to be written if the kernel chooses to swap that tmpfs out to recover memory (as opposed to a regular filesystem, where the kernel must assume that the data should persist indefinitely). That then led to the problem that some of these tmpfs-backed directories were actually a mixture of temporary and permanent state. For example, /var/run (now just /run) was a popular tmpfs because it was used for storing pid files - but it also became a home to daemon-specific directories that needed to exist for the daemon to operate correctly. The directories' contents could be safely lost across reboots, but the directories' existence and permissions could not be. Various ad-hoc mechanisms were put in place (such as checkpath) to recreate these directories at need. At some point, the tmpfiles concept took hold: a declarative listing of objects that were stored in tmpfs-backed directories, but which should be created anew with each boot. Unfortunately, the declarative language is an ad-hoc mess too, and some of its features cannot be implemented correctly using only a POSIX-compatible shell. As I understand it, safely implementing the tmpfiles specification requires one of (a) using functionality not available in POSIX shell, (b) restricting tmpfiles configuration files not to invoke the dangerous functionality, or (c) guaranteeing that no untrusted code can run while the opentmpfiles processor is running. (For option (c), some code changes may still be needed, but if you can assume no race conditions, it's a solvable hard problem instead of an impossible problem.) | mv wrote: | | Hu wrote: | | Using exec -a, the shell can run one program, but claim some other name. |
exec -a is a bashism. |
I would prefer a fallback path that relies on a bashism over no fallback at all. As is, udev upstream's packaging is confusing and may mislead users into breaking things, to the point that a relevant Gentoo maintainer felt the need to mention the problem in a news item. Giving the initscript a fallback to recover from that strange behavior beats having users posting about broken systems due to the udev symlink being absent. | Hund wrote: | Why couldn't they use whatever Alpine Linux or port/adapt whatever {Open,Free}BSD is using? systemd-tmpfiles can't be the only option out there.  |
I do not know what the *BSDs are using, or if they even adopted tmpfiles at all. This question would be better addressed by a Gentoo maintainer involved in the decision to move everyone over to systemd-tmpfiles. Perhaps such a maintainer will speak up here. | Tony0945 wrote: | | If you run " <=sys-apps/openrc-0.17" from local overlay, you don't need sys-apps/opentmpfiles. |
For those wondering, this is because old openrc had its own tmpfiles processor. At some point, that was moved to its own package. I am not aware of whether the bundled tmpfiles processor is likewise vulnerable to the problems that led to the masking of opentmpfiles. | Tony0945 wrote: | In any case: | Code: | ~ $ equery d virtual/tnpfiles
* These packages depend on virtual/tnpfiles: |
|
Do you get the same empty list if you spell the package name correctly? For me, logrotate, samba, eix, and lvm2 all depend on it. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Oct 20, 2021 2:22 am Post subject: |
|
|
Ooops! Sorry Hu. Another slip of the finger.
| Code: | ~ $ equery d virtual/tmpfiles
* These packages depend on virtual/tmpfiles:
app-admin/logrotate-3.18.1-r1 (virtual/tmpfiles)
app-admin/sudo-1.9.6_p1-r2 (virtual/tmpfiles)
app-emulation/virtualbox-6.1.24 (virtual/tmpfiles)
app-portage/eix-0.35.2 (virtual/tmpfiles)
app-portage/gentoolkit-0.5.1-r1 (virtual/tmpfiles)
gnome-base/gvfs-1.48.1-r1 (fuse ? virtual/tmpfiles)
net-fs/samba-4.13.9-r3 (virtual/tmpfiles)
net-misc/dhcp-4.4.2_p1-r1 (virtual/tmpfiles)
net-vpn/openvpn-2.5.2-r2 (virtual/tmpfiles)
sys-apps/dbus-1.12.20-r3 (systemd ? virtual/tmpfiles)
sys-apps/man-db-2.9.4-r1 (virtual/tmpfiles)
sys-power/apcupsd-3.14.14-r3 (virtual/tmpfiles)
|
gvfs is installed with USE=fuse. dbus is installed with -systemd which is the forst USE entry in my make.conf.
All seem to be running OK. dbus is not even launched at boot because I don't start the daemon. It's only there because portage requires it. Some office/Mate programs give error messages lke "can't connect to dbus" but no functionality that I use is affected. Can't speak to all Mate/Office functionality.
Again, running Roy Marples' OpenRC. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Wed Oct 20, 2021 8:47 am Post subject: |
|
|
If the promise I quoted on my earlier post is to be trusted, then we should have no problem using systemd-tmpfiles. udev on the other hand isn't included in this "promise".
IMO we'd need a new device manager written from scratch (or maybe fork mdev or like), not one that constantly reverts back what upstream does.
For now I'm using systemd-udev. It works currently without systemd just fine. I'll wait and see. Maybe this new eudev will stray from following systemd-udev to become it's own real project.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Oct 20, 2021 1:49 pm Post subject: |
|
|
| Zucca wrote: | | IMO we'd need a new device manager written from scratch (or maybe fork mdev or like), not one that constantly reverts back what upstream does. |
AMEN!
First someone has to write a specification. Too much of open source is some programmer just "winging it". Very unprofessional. Open source used to be written by professionals doing it their way, unconstrained by management. Forks were welcome, lately (last twenty years or so) it's been about making a reputation to get a job with Microsoft/IBM. Just a stepping stone, no longer a holy crusade. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Oct 20, 2021 3:42 pm Post subject: |
|
|
Eudev should have always been a rewrite, adhering to input and output specs (I'm pretty sure FDO has specs somewhere)
I feel the same about elogind.
Or someone (with lots of time on their hands) should dismantle systemd, and truly modularize it, so all pieces could be used or dropped as needed.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Wed Oct 20, 2021 7:20 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Or someone (with lots of time on their hands) should dismantle systemd, and truly modularize it, so all pieces could be used or dropped as needed. |
I'm hoping InitWare folks will do that.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4148
Location: Bavaria
|
| Posted: Thu Oct 21, 2021 1:28 am Post subject: |
|
|
| Zucca wrote: | | I'm hoping InitWare folks will do that. |
Do you know where it comes from ? ... who is behind this project ? (I didnt find anything about this). |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland
|
| Posted: Thu Oct 21, 2021 3:49 am Post subject: |
|
|
I know very little about that, but there's an IRC channel: #initware@libera.chat.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Thu Oct 21, 2021 6:04 pm Post subject: |
|
|
I'm more concerned about what seems like One Acceptable Solution to any given problem, especially when pushed by special interests.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
FR3141
n00b
Joined: 13 Jan 2018
Posts: 39
|
| Posted: Sat Nov 06, 2021 11:49 am Post subject: |
|
|
| Zucca wrote: |
IMO we'd need a new device manager written from scratch (or maybe fork mdev or like), not one that constantly reverts back what upstream does.
|
All those Gentoo users that wish to liberate themselves from udev/eudev may want to consider the example of this GNU/Linux distro:
https://kisslinux.org/wiki/device-management
https://github.com/kisslinux
KISS is a very interesting distro and could provide some valuable pointers for Gentoo users.
I am strongly considering mdev for my systems but libinput, AFAIK, is the main stumbling block. But the KISS distro describes a workaround. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
