Removal of /run/utmp and /var/log/wtmp
Hi, I wrote already about Y2038 and the problems with utmp and wtmp. Since we have already solutions active for some weeks, we will now do the next steps: We replaced /var/log/wtmp with wtmpdb some months ago. /usr/bin/last does not use /var/log/wtmp anymore since quite some time, too. So the next logical step will be, that we don't create /var/log/wtmp anymore. Existing files will not be deleted and many tools will still write into it, but new installations will not create it anymore. After this, we have to find the applications, which don't use the glibc interface and try to manage this file at their own. They could still create that file. The majority of known applications are using logind meanwhile instead of /run/utmp. The bug reports are all fixed meanwhile, so we will go the next step: disabling /run/utmp. A systemd with disabled utmp support will be submitted most likely next week, and then we will see how long it takes to get it through the stagings. There are still some open SRs which the package maintainers ignores since several weeks. This should not affect anybody, but if yes, please complain to the responsible package maintainers. If you know about an important application still reading (not writing) /run/utmp, please speak up now. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Thursday 2023-10-19 10:24, Thorsten Kukuk wrote:
The majority of known applications are using logind meanwhile instead of /run/utmp.
I used to be able to see in the output of /usr/bin/w all the xterms I had open. This is no longer the case, and I see that as a regression. There are no active SRs for either of the two.
On Thu, Oct 19, Jan Engelhardt wrote:
I used to be able to see in the output of /usr/bin/w all the xterms I had open. This is no longer the case, and I see that as a regression.
There are no active SRs for either of the two.
From "man utmp": "utmp, wtmp - login records" Your xterm session is no login session, so that xterm writes utmp entries was wrong from the beginning (and gnome-terminal is not doing it for this reason). Historical, xterm wrote utmp entries so that the user sees wall messages. But this needs to be solved by the desktop environment, not by the wrong claim to be a login session. So it's not a regression, it's a bug fix. And maybe even a security fix, as you are now no longer able to block root from login by opening too many xterms. Fixes at the same time the problem, that monitoring tools showed always a wrong number of logged in users if somebody did use xterm. And it cannot be that big problem if you notice that only today. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 19.10.23 10:24, Thorsten Kukuk wrote:
If you know about an important application still reading (not writing) /run/utmp, please speak up now.
The most important application of the whole distribution: busybox -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thu, Oct 19, Stefan Seyfried via openSUSE Factory wrote:
On 19.10.23 10:24, Thorsten Kukuk wrote:
If you know about an important application still reading (not writing) /run/utmp, please speak up now.
The most important application of the whole distribution: busybox
We don't support busybox as replacement for coreutils or util-linux on the distro, as we know that the busybox tools are incompatible with many other core utilities. For repairing the system utmp is not needed and inside containers, utmp and wtmp don't exist at all. So not a real problem, and since we use busybox mainly in containers, not even wanted. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Thu, 19 Oct 2023 12:50:04 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
We don't support busybox as replacement for coreutils or util-linux on the distro, as we know that the busybox tools are incompatible with many other core utilities.
Yet, you use busybox in containers. OK there, but not outside of a container? Why?
[...] So not a real problem, and since we use busybox mainly in containers, not even wanted.
-- Robert Webb
On Thu, Oct 19, Robert Webb via openSUSE Factory wrote:
On Thu, 19 Oct 2023 12:50:04 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
We don't support busybox as replacement for coreutils or util-linux on the distro, as we know that the busybox tools are incompatible with many other core utilities.
Yet, you use busybox in containers. OK there, but not outside of a container? Why?
I don't understand your question. The quote contains the reason why we don't support it outside a container as coreutils or util-linux replacement, what else do you want to know? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Fri, 20 Oct 2023 06:40:06 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
On Thu, Oct 19, Robert Webb via openSUSE Factory wrote:
On Thu, 19 Oct 2023 12:50:04 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
We don't support busybox as replacement for coreutils or util-linux on the distro, as we know that the busybox tools are incompatible with many other core utilities.
Yet, you use busybox in containers. OK there, but not outside of a container? Why?
I don't understand your question. The quote contains the reason why we don't support it outside a container as coreutils or util-linux replacement, what else do you want to know?
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise. -- Robert Webb
On Fri, Oct 20, Robert Webb via openSUSE Factory wrote:
On Fri, 20 Oct 2023 06:40:06 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
On Thu, Oct 19, Robert Webb via openSUSE Factory wrote:
On Thu, 19 Oct 2023 12:50:04 +0000, Thorsten Kukuk <kukuk@suse.de> wrote:
We don't support busybox as replacement for coreutils or util-linux on the distro, as we know that the busybox tools are incompatible with many other core utilities.
Yet, you use busybox in containers. OK there, but not outside of a container? Why?
I don't understand your question. The quote contains the reason why we don't support it outside a container as coreutils or util-linux replacement, what else do you want to know?
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs. And none of them supports utmp, wtmp or something similar. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist. Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Hi, Am Freitag, 20. Oktober 2023, 14:35:40 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist.
Correct.
Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Yes, by having some other package that is part of the transaction suggest the non-busybox option. This is already done by patterns-base-base, but this is not always installed and probably also incomplete... Cheers, Fabian
On Fri, Oct 20, 2023 at 3:46 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:35:40 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist.
Correct.
Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Yes, by having some other package that is part of the transaction suggest the non-busybox option. This is already done by patterns-base-base, but this is not always installed and probably also incomplete...
You probably misunderstood the problem. andrei@tumbleweed:~> zypper se --requires /usr/bin/patch Loading repository data... Reading installed packages... S | Name | Summary | Type --+-----------------+------------------------------------+-------- | flatpak-builder | Tool to build flatpaks from source | package | lsb | LSB Fake Package | package andrei@tumbleweed:~> zypper se --provides -x /usr/bin/patch Loading repository data... Reading installed packages... S | Name | Summary | Type --+---------------+---------------------------------+-------- | busybox-patch | Busybox applets replacing patch | package | patch | GNU patch | package andrei@tumbleweed:~> How are you going to ensure that installing flatpak-builder installs "patch" and not "busybox-patch"? By always pre-installing "patch" on every system?
Hi, Am Freitag, 20. Oktober 2023, 14:58:32 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:46 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:35:40 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist.
Correct.
Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Yes, by having some other package that is part of the transaction suggest the non-busybox option. This is already done by patterns-base-base, but this is not always installed and probably also incomplete...
You probably misunderstood the problem.
You probably misunderstood my answer :P
andrei@tumbleweed:~> zypper se --requires /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+-----------------+------------------------------------+-------- | flatpak-builder | Tool to build flatpaks from source | package | lsb | LSB Fake Package | package andrei@tumbleweed:~> zypper se --provides -x /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+---------------+---------------------------------+-------- | busybox-patch | Busybox applets replacing patch | package | patch | GNU patch | package andrei@tumbleweed:~>
How are you going to ensure that installing flatpak-builder installs "patch" and not "busybox-patch"? By always pre-installing "patch" on every system?
If patterns-base-base has Suggests: patch and is installed on the system, "zypper in /usr/bin/patch" will pick patch, not busybox-patch. Cheers, Fabian
On Fri, Oct 20, 2023 at 4:01 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:58:32 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:46 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:35:40 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist.
Correct.
Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Yes, by having some other package that is part of the transaction suggest the non-busybox option. This is already done by patterns-base-base, but this is not always installed and probably also incomplete...
You probably misunderstood the problem.
You probably misunderstood my answer :P
That's quite possible.
andrei@tumbleweed:~> zypper se --requires /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+-----------------+------------------------------------+-------- | flatpak-builder | Tool to build flatpaks from source | package | lsb | LSB Fake Package | package andrei@tumbleweed:~> zypper se --provides -x /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+---------------+---------------------------------+-------- | busybox-patch | Busybox applets replacing patch | package | patch | GNU patch | package andrei@tumbleweed:~>
How are you going to ensure that installing flatpak-builder installs "patch" and not "busybox-patch"? By always pre-installing "patch" on every system?
If patterns-base-base has
Suggests: patch
and is installed on the system, "zypper in /usr/bin/patch" will pick patch, not busybox-patch.
But patterns-base-base will *not* be part of the transaction when installing flatpak-builder. andrei@tumbleweed:~> sudo zypper in flatpak-builder Loading repository data... Reading installed packages... Resolving package dependencies... The following 81 NEW packages are going to be installed: binutils bubblewrap busybox busybox-patch dconf debugedit dwz elfutils flatpak flatpak-builder fuse3 gdk-pixbuf-query-loaders git-core glib-networking gsettings-desktop-schemas libappstream4 libarchive13 libasm1 libasound2 libavahi-client3 libavahi-common3 libavc1394-0 libbluetooth3 libcamera0_1 libcamera-base0_1 libconfig++11 libctf0 libctf-nobfd0 libdconf1 libdrm2 libfdk-aac2 libffado2 libFLAC12 libflatpak0 libfuse3-3 libgdk_pixbuf-2_0-0 libglibmm-2_4-1 libgnutls30 libhogweed6 libiec61883-0 libjbig2 libjpeg8 libjson-glib-1_0-0 liblc3-1 libldac2 liblilv-0-0 libmysofa1 libnettle8 libogg0 libopus0 libostree libostree-1-1 libpipewire-0_3-0 libpng16-16 libpulse0 libraw1394-11 libsbc1 libserd-0-0 libsha1detectcoll1 libsndfile1 libsord-0-0 libsoup-2_4-1 libspeex1 libsratom-0-0 libstemmer1d libtiff6 libunwind8 libvorbis0 libvorbisenc2 libvulkan1 libwebrtc-audio-processing-1-3 libXau6 libxcb1 libxml++-3_0-1 libxmlb2 pipewire-libjack-0_3 pipewire-modules-0_3 pipewire-spa-plugins-0_2 system-user-flatpak xdg-dbus-proxy xdg-desktop-portal 81 new packages to install. Actually, this installation (WSL image) does not even have the Base System pattern.
Hi, Am Freitag, 20. Oktober 2023, 15:12:56 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 4:01 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:58:32 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:46 PM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Freitag, 20. Oktober 2023, 14:35:40 CEST schrieb Andrei Borzenkov:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
> > I guess you are implying that containers have no core utilities. > That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist.
Correct.
Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
Yes, by having some other package that is part of the transaction suggest the non-busybox option. This is already done by patterns-base-base, but this is not always installed and probably also incomplete...
You probably misunderstood the problem.
You probably misunderstood my answer :P
That's quite possible.
andrei@tumbleweed:~> zypper se --requires /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+-----------------+------------------------------------+-------- | flatpak-builder | Tool to build flatpaks from source | package | lsb | LSB Fake Package | package andrei@tumbleweed:~> zypper se --provides -x /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+---------------+---------------------------------+-------- | busybox-patch | Busybox applets replacing patch | package | patch | GNU patch | package andrei@tumbleweed:~>
How are you going to ensure that installing flatpak-builder installs "patch" and not "busybox-patch"? By always pre-installing "patch" on every system?
If patterns-base-base has
Suggests: patch
and is installed on the system, "zypper in /usr/bin/patch" will pick patch, not busybox-patch.
But patterns-base-base will *not* be part of the transaction when installing flatpak-builder.
Already installed packages are included as well, unless they will be uninstalled (I think). I wrote "transaction" because it's IMO less obvious that for the initial installation it will be honored. Compare e.g. zypper --installroot $PWD/empty in --no-recommends /usr/bin/killall to zypper --installroot $PWD/empty in --no-recommends pattern:base /usr/bin/killall
andrei@tumbleweed:~> sudo zypper in flatpak-builder Loading repository data... Reading installed packages... Resolving package dependencies...
The following 81 NEW packages are going to be installed: binutils bubblewrap busybox busybox-patch dconf debugedit dwz elfutils flatpak flatpak-builder fuse3 gdk-pixbuf-query-loaders git-core glib-networking gsettings-desktop-schemas libappstream4 libarchive13 libasm1 libasound2 libavahi-client3 libavahi-common3 libavc1394-0 libbluetooth3 libcamera0_1 libcamera-base0_1 libconfig++11 libctf0 libctf-nobfd0 libdconf1 libdrm2 libfdk-aac2 libffado2 libFLAC12 libflatpak0 libfuse3-3 libgdk_pixbuf-2_0-0 libglibmm-2_4-1 libgnutls30 libhogweed6 libiec61883-0 libjbig2 libjpeg8 libjson-glib-1_0-0 liblc3-1 libldac2 liblilv-0-0 libmysofa1 libnettle8 libogg0 libopus0 libostree libostree-1-1 libpipewire-0_3-0 libpng16-16 libpulse0 libraw1394-11 libsbc1 libserd-0-0 libsha1detectcoll1 libsndfile1 libsord-0-0 libsoup-2_4-1 libspeex1 libsratom-0-0 libstemmer1d libtiff6 libunwind8 libvorbis0 libvorbisenc2 libvulkan1 libwebrtc-audio-processing-1-3 libXau6 libxcb1 libxml++-3_0-1 libxmlb2 pipewire-libjack-0_3 pipewire-modules-0_3 pipewire-spa-plugins-0_2 system-user-flatpak xdg-dbus-proxy xdg-desktop-portal
81 new packages to install.
Actually, this installation (WSL image) does not even have the Base System pattern.
In that case it won't help of course.
On Friday 2023-10-20 14:58, Andrei Borzenkov wrote:
andrei@tumbleweed:~> zypper se --requires /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+-----------------+------------------------------------+-------- | flatpak-builder | Tool to build flatpaks from source | package | lsb | LSB Fake Package | package andrei@tumbleweed:~> zypper se --provides -x /usr/bin/patch Loading repository data... Reading installed packages...
S | Name | Summary | Type --+---------------+---------------------------------+-------- | busybox-patch | Busybox applets replacing patch | package | patch | GNU patch | package andrei@tumbleweed:~>
How are you going to ensure that installing flatpak-builder installs "patch" and not "busybox-patch"? By always pre-installing "patch" on every system?
If flatpak-builder requires GNU patch, then the .spec file should Requires:patch, not Requires:/usr/bin/patch. If f-b does not care, then Requires:/usr/bin/patch is good enough.
I had a case where I was building an installer with kiwi. It kept pulling the busybox package which later broke other packages explicit requests for the standard version. Turns out that in one step in the build, no preference was given, and so snapper took the repos in alphabetic order and selected the busybox version. The solution was to explicitly request the standard package so the busybox one did not get selected. This was discussed on the kiwi mailing list recently. On Fri, Oct 20, 2023 at 2:36 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Oct 20, 2023 at 3:26 PM Thorsten Kukuk <kukuk@suse.de> wrote:
I guess you are implying that containers have no core utilities. That is something I didn't know, and assumed otherwise.
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
Which reminds me. There were multiple reports on forums about zypper selecting busybox as a dependency for some binary (/usr/bin/xxx). My best guess is that zypper simply takes the first package in alphabetical order when several choices exist. Is there any way to mark some packages as preferred *at runtime*? OBS solves it in project config, but it does not help in this case.
-- Roger Oberholtzer
On 10/20/23 14:25, Thorsten Kukuk wrote:
There are base containers, which include coreutils and util-linux, and there is our busybox base container, which only includes busybox and the symlinks for the tools. So both exists, depending on your needs.
FWIW: the GNU coreutils package also allows building as a single-binary executable to save disk space. The single 'coreutils' binary is a bit larger of course, but given how often one of the tools is used the kernel will cache it anyway. In OBS, there's the flavor package called 'coreutils-single' which uses shebang wrappers for each utility (using './configure --enable-single-binary'). There'd also be an alternative to use symlinks for each tool to the 'coreutils' single binary (using './configure --enable-single-binary=symlinks'), but there has not been a request to add that flavor in OBS yet. Both alternatives to the standard coreutils package could save quite some space e.g. for containers; for a regular distribution, the difference is probably too small: ~/coreutils/build> du -h */inst/bin 28M regular/inst/bin 5.7M single-shebang/inst/bin 5.3M single-symlinks/inst/bin Have a nice day, Berny
participants (8)
-
Andrei Borzenkov -
Bernhard Voelker -
Fabian Vogt -
Jan Engelhardt -
Robert Webb -
Roger Oberholtzer -
Stefan Seyfried -
Thorsten Kukuk