[IMPORTANT] Switching from wtmp to wtmpdb
Hi, as already told ;), wtmp has a Y2038 problem which the glibc developers don't plan to fix, but instead they want deprecate that API. (For background see https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/) On openSUSE Tumbleweed/MicroOS/... we introduced meanwhile wtmpdb, which solves the Y2038 problem and some others, too. "wtmpdb last" should work already today and show you similar output compared with "last" itself. The next and final step will be, making "last" a link to "wtmpdb last" and rename the old last to "last.legacy". There are currently no plans to disable writing of wtmp entries completly, I expect that this will come most likely together with utmp. So the applications reading wtmp directly (currently I'm only aware of accounts-daemon, maybe samba, haven't analyzed that code yet) should continue to work. The other 99% of applications accessing wtmp do only create new entries, this should cause no issues. But: due to a one year old bug in systemd-presets-common-SUSE, the service files didn't got always enabled. IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer This is only necessary if you did updates, not for systems which got fresh installed this week. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Hi Thorsten, On 28.06.23 at 10:40 Thorsten Kukuk wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
This is only necessary if you did updates, not for systems which got fresh installed this week.
Seems like until now I have not yet gotten this package installed. Thus the services cannot be found. When did (or will) this package arrive? Should this come as a "Recommends" (which are disabled on this system)? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Wed, Jun 28, Johannes Kastl wrote:
Hi Thorsten,
On 28.06.23 at 10:40 Thorsten Kukuk wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
This is only necessary if you did updates, not for systems which got fresh installed this week.
Seems like until now I have not yet gotten this package installed. Thus the services cannot be found.
When did (or will) this package arrive? Should this come as a "Recommends" (which are disabled on this system)?
Depends on the openSUSE flavor, some have it as requires, others only as Recommends. If people disable by themself "recommends", then yes, as usual, they have to manually track and install new packages and features. In this case: "zypper in wtmpdb" 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Am 28.06.23 um 13:39 schrieb Thorsten Kukuk:
On Wed, Jun 28, Johannes Kastl wrote:
Hi Thorsten,
On 28.06.23 at 10:40 Thorsten Kukuk wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
This is only necessary if you did updates, not for systems which got fresh installed this week.
Seems like until now I have not yet gotten this package installed. Thus the services cannot be found.
When did (or will) this package arrive? Should this come as a "Recommends" (which are disabled on this system)?
Depends on the openSUSE flavor, some have it as requires, others only as Recommends. If people disable by themself "recommends", then yes, as usual, they have to manually track and install new packages and features.
In this case: "zypper in wtmpdb"
Thorsten
hi thorsten, sorry still unclear to me: i have never disabled or changed requires/recomends wtmpdb is not installed. so the services are not on my systems. MUST i now install wtmpdb AND after this enable the services ? OR did i have to do nothing and everithing works as it should? simoN -- www.becherer.de
On Wed, Jun 28, Simon Becherer wrote:
hi thorsten, sorry still unclear to me:
i have never disabled or changed requires/recomends wtmpdb is not installed. so the services are not on my systems. MUST i now install wtmpdb AND after this enable the services ? OR did i have to do nothing and everithing works as it should?
Maybe you have a very old system, where the current base patterns are not installed. In this case, new core packages will not be installed, too. "zypper in wtmpdb" will install it, and if your system is up-to-date, the services should be automatically enabled. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 6/28/23 11:02, Thorsten Kukuk wrote:
On Wed, Jun 28, Simon Becherer wrote:
hi thorsten, sorry still unclear to me:
i have never disabled or changed requires/recomends wtmpdb is not installed. so the services are not on my systems. MUST i now install wtmpdb AND after this enable the services ? OR did i have to do nothing and everithing works as it should? Maybe you have a very old system, where the current base patterns are not installed. In this case, new core packages will not be installed, too.
"zypper in wtmpdb" will install it, and if your system is up-to-date, the services should be automatically enabled.
Thorsten
Hi Thorsten, My system was installed 03/2021 and I am a few builds back running 20230616. The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled. Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ? One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28". man wtmpdb says ( so that explains it ) TIMEmust be in the format "YYYY-MM-DD HH:MM:SS". but it would be nice if it would default the time like last does. Thanks! -- Regards, Joe
Jun 28, 2023 17:19:15 Joe Salmeri <jmscdba@gmail.com>:
On 6/28/23 11:02, Thorsten Kukuk wrote:
On Wed, Jun 28, Simon Becherer wrote:
hi thorsten, sorry still unclear to me:
i have never disabled or changed requires/recomends wtmpdb is not installed. so the services are not on my systems. MUST i now install wtmpdb AND after this enable the services ? OR did i have to do nothing and everithing works as it should?
Maybe you have a very old system, where the current base patterns are not installed. In this case, new core packages will not be installed, too.
"zypper in wtmpdb" will install it, and if your system is up-to-date, the services should be automatically enabled.
Thorsten
Hi Thorsten,
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28".
man wtmpdb says ( so that explains it )
TIME must be in the format *"YYYY-MM-DD HH:MM:SS"*.
but it would be nice if it would default the time like last does.
Thanks!
-- Regards,
Joe One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28".
While you need to put the full hour:min:sec, you need to enclose the format in double quotes for it to work at all Like `wtmpdb last -s "2023-06-28 00:00:00"` will work, while `wtmpdb last -s 20 23-06-28 00:00:00` won't Nicolas
On 6/28/23 11:34, Nicolas FORMICHELLA wrote:
Jun 28, 2023 17:19:15 Joe Salmeri<jmscdba@gmail.com>:
On 6/28/23 11:02, Thorsten Kukuk wrote:
On Wed, Jun 28, Simon Becherer wrote:
hi thorsten, sorry still unclear to me:
i have never disabled or changed requires/recomends wtmpdb is not installed. so the services are not on my systems. MUST i now install wtmpdb AND after this enable the services ? OR did i have to do nothing and everithing works as it should? Maybe you have a very old system, where the current base patterns are not installed. In this case, new core packages will not be installed, too.
"zypper in wtmpdb" will install it, and if your system is up-to-date, the services should be automatically enabled.
Thorsten Hi Thorsten,
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28".
man wtmpdb says ( so that explains it )
TIME must be in the format *"YYYY-MM-DD HH:MM:SS"*.
but it would be nice if it would default the time like last does.
Thanks!
-- Regards,
Joe One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28". While you need to put the full hour:min:sec, you need to enclose the format in double quotes for it to work at all
Like `wtmpdb last -s "2023-06-28 00:00:00"` will work, while `wtmpdb last -s 20 23-06-28 00:00:00` won't
Nicolas
Correct because the date time format has a space in it. I was suggesting that they default to midnight like last currently does. Another issue is that last-s"2023-06-28 00:00:00"Returns joe pts/4 :0 Wed Jun 28 01:00 - 01:00 (00:00) wtmp begins Sun May 14 00:42:54 2023 whereas wtmpdb last-s"2023-06-28 00:00:00"Returns /var/lib/wtmpdb/wtmp.db begins Mon May 15 12:51:46 2023 This could be because I am still on 20230616 and it has in one of the 9 newer TW builds, but if it hasn't then it appears to be a bug. -- Regards, Joe
On Wed, Jun 28, Joe Salmeri wrote:
last -s "2023-06-28 00:00:00"
Returns
joe pts/4 :0 Wed Jun 28 01:00 - 01:00 (00:00)
wtmp begins Sun May 14 00:42:54 2023
whereas
wtmpdb last -s "2023-06-28 00:00:00"
Returns
/var/lib/wtmpdb/wtmp.db begins Mon May 15 12:51:46 2023
This could be because I am still on 20230616 and it has in one of the 9 newer TW builds, but if it hasn't then it appears to be a bug.
Works for me: # last -s "2023-06-24 00:00:00" kukuk pts/0 fd21:4d9a:50d0:b Thu Jun 29 08:04 still logged in reboot system boot 6.3.9-1-default Thu Jun 29 04:01 still running kukuk pts/0 fd21:4d9a:50d0:b Wed Jun 28 08:16 - 16:18 (08:01) reboot system boot 6.3.9-1-default Wed Jun 28 04:01 - 04:00 (23:59) kukuk pts/1 fd21:4d9a:50d0:b Tue Jun 27 08:20 - 03:59 (19:39) kukuk pts/0 172.17.0.133 Tue Jun 27 06:54 - 09:25 (02:31) reboot system boot 6.3.9-1-default Tue Jun 27 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Mon Jun 26 07:02 - 03:59 (20:57) reboot system boot 6.3.9-1-default Mon Jun 26 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Sun Jun 25 10:55 - 13:14 (02:19) reboot system boot 6.3.7-1-default Sun Jun 25 04:01 - 04:00 (23:59) reboot system boot 6.3.7-1-default Sat Jun 24 04:01 - 04:00 (23:59) wtmp begins Sat Apr 29 03:59:43 2023 # wtmpdb last -s "2023-06-24 00:00:00" kukuk pts/0 fd21:4d9a:50d0:b Thu Jun 29 08:04 - still logged in reboot system boot 6.3.9-1-default Thu Jun 29 04:01 - still running kukuk pts/0 fd21:4d9a:50d0:b Wed Jun 28 08:16 - 16:18 (08:01) reboot system boot 6.3.9-1-default Wed Jun 28 04:01 - 04:00 (23:59) kukuk pts/1 fd21:4d9a:50d0:b Tue Jun 27 08:20 - 03:59 (19:39) kukuk pts/0 172.17.0.133 Tue Jun 27 06:54 - 09:25 (02:31) reboot system boot 6.3.9-1-default Tue Jun 27 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Mon Jun 26 07:02 - 03:59 (20:57) reboot system boot 6.3.9-1-default Mon Jun 26 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Sun Jun 25 10:55 - 13:14 (02:19) reboot system boot 6.3.7-1-default Sun Jun 25 04:01 - 04:00 (23:59) reboot system boot 6.3.7-1-default Sat Jun 24 04:01 - 04:00 (23:59) /var/lib/wtmpdb/wtmp.db begins Mon Jun 12 08:00:56 2023 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 6/29/23 03:08, Thorsten Kukuk wrote:
On Wed, Jun 28, Joe Salmeri wrote:
last -s "2023-06-28 00:00:00"
Returns
joe pts/4 :0 Wed Jun 28 01:00 - 01:00 (00:00)
wtmp begins Sun May 14 00:42:54 2023
whereas
wtmpdb last -s "2023-06-28 00:00:00"
Returns
/var/lib/wtmpdb/wtmp.db begins Mon May 15 12:51:46 2023
This could be because I am still on 20230616 and it has in one of the 9 newer TW builds, but if it hasn't then it appears to be a bug. Works for me:
# last -s "2023-06-24 00:00:00" kukuk pts/0 fd21:4d9a:50d0:b Thu Jun 29 08:04 still logged in reboot system boot 6.3.9-1-default Thu Jun 29 04:01 still running kukuk pts/0 fd21:4d9a:50d0:b Wed Jun 28 08:16 - 16:18 (08:01) reboot system boot 6.3.9-1-default Wed Jun 28 04:01 - 04:00 (23:59) kukuk pts/1 fd21:4d9a:50d0:b Tue Jun 27 08:20 - 03:59 (19:39) kukuk pts/0 172.17.0.133 Tue Jun 27 06:54 - 09:25 (02:31) reboot system boot 6.3.9-1-default Tue Jun 27 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Mon Jun 26 07:02 - 03:59 (20:57) reboot system boot 6.3.9-1-default Mon Jun 26 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Sun Jun 25 10:55 - 13:14 (02:19) reboot system boot 6.3.7-1-default Sun Jun 25 04:01 - 04:00 (23:59) reboot system boot 6.3.7-1-default Sat Jun 24 04:01 - 04:00 (23:59)
wtmp begins Sat Apr 29 03:59:43 2023 # wtmpdb last -s "2023-06-24 00:00:00" kukuk pts/0 fd21:4d9a:50d0:b Thu Jun 29 08:04 - still logged in reboot system boot 6.3.9-1-default Thu Jun 29 04:01 - still running kukuk pts/0 fd21:4d9a:50d0:b Wed Jun 28 08:16 - 16:18 (08:01) reboot system boot 6.3.9-1-default Wed Jun 28 04:01 - 04:00 (23:59) kukuk pts/1 fd21:4d9a:50d0:b Tue Jun 27 08:20 - 03:59 (19:39) kukuk pts/0 172.17.0.133 Tue Jun 27 06:54 - 09:25 (02:31) reboot system boot 6.3.9-1-default Tue Jun 27 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Mon Jun 26 07:02 - 03:59 (20:57) reboot system boot 6.3.9-1-default Mon Jun 26 04:01 - 04:00 (23:59) kukuk pts/0 fd21:4d9a:50d0:b Sun Jun 25 10:55 - 13:14 (02:19) reboot system boot 6.3.7-1-default Sun Jun 25 04:01 - 04:00 (23:59) reboot system boot 6.3.7-1-default Sat Jun 24 04:01 - 04:00 (23:59)
/var/lib/wtmpdb/wtmp.db begins Mon Jun 12 08:00:56 2023
Thorsten
Thorsten, I am on build 20230616, are you on a newer build ? -- Regards, Joe
On Wed, Jun 28, Joe Salmeri wrote:
One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28".
man wtmpdb says ( so that explains it )
TIME must be in the format "YYYY-MM-DD HH:MM:SS".
but it would be nice if it would default the time like last does.
Ok, "YYYY-MM-DD", "today" and "yesterday" will also work after the next update. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 6/29/23 05:48, Thorsten Kukuk wrote:
On Wed, Jun 28, Joe Salmeri wrote:
One thing I noticed is that "last -s 2023-06-28" works properly and returns since midnight, whereas "wtmpdb last -s 2023-06-28" returns "Invalid time value 2023-06-28".
man wtmpdb says ( so that explains it )
TIME must be in the format "YYYY-MM-DD HH:MM:SS".
but it would be nice if it would default the time like last does. Ok, "YYYY-MM-DD", "today" and "yesterday" will also work after the next update.
Thorsten
Great, thanks for your efforts!
Hi Thorsten, When I wrote that I was still running 20230616 but after updating to TW 20230705, it is still not accepting "YYYY-MM-DD", "today", or "yesterday". Has that change been submitted yet? Thank you.
Am 28.06.23 um 17:18 schrieb Joe Salmeri:
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
You have to enable both manually, as the update procedure doesn't know whether you turned them off because you don't want them to run. Until both are enabled, you will not get valid information from wtmpdb. Regards, Oliver -- PGP Public Key available at https://pgp.mit.edu/ Key fingerprint = 3264 280C 05B1 572F 3F0B 42B8 1E7B 2D9D 063B D507
On 6/29/23 15:40, Oliver Schwabedissen wrote:
Am 28.06.23 um 17:18 schrieb Joe Salmeri:
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
You have to enable both manually, as the update procedure doesn't know whether you turned them off because you don't want them to run. Until both are enabled, you will not get valid information from wtmpdb.
Regards,
Oliver
Thanks for the clarification Oliver -- Regards, Joe
Oliver Schwabedissen composed on 2023-06-29 21:40 (UTC+0200):
schrieb Joe Salmeri:
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
You have to enable both manually, as the update procedure doesn't know whether you turned them off because you don't want them to run. Until both are enabled, you will not get valid information from wtmpdb.
Last night I dup'd to 20230627 from 20230612 or so. After zypper ref, I zypper in'd wtmpdb, then checked their status to find disabled. Then I dup'd. After, I checked again, and both were enabled. Earlier in the day on another PC, I dup'd to 27 from about 20230512 or so, then installed wtmpdb to find both enabled. Is what wtmp/wtmpdb do something mere mortal TW users actually use? Is it rather a developer thing? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Thu, Jun 29, Felix Miata wrote:
Last night I dup'd to 20230627 from 20230612 or so. After zypper ref, I zypper in'd wtmpdb, then checked their status to find disabled. Then I dup'd. After, I checked again, and both were enabled. Earlier in the day on another PC, I dup'd to 27 from about 20230512 or so, then installed wtmpdb to find both enabled.
Is what wtmp/wtmpdb do something mere mortal TW users actually use? Is it rather a developer thing?
wtmp/wtmpdb contains the data, when which user did login/logout and when the machine got rebooted. In the "good old times", so 20-40 years ago, it was also used for some other stuff like storing the date at which the system clock got adjusted. But I haven't found any code doing this anymore. If you use "/usr/bin/last", you are using wtmp/wtmpdb. If you never use that tool, you don't need the database. It's not a developer thing, more an sysadmin thing. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Thu, Jun 29, Oliver Schwabedissen wrote:
Am 28.06.23 um 17:18 schrieb Joe Salmeri:
My system was installed 03/2021 and I am a few builds back running 20230616.
The wutmpdb package installed, but wtmpdb-rotate.timer and wtmpdb-update-boot.service are both disabled.
Should I enable both ( as you mentioned ) or will that happen when I update to the latest build ?
You have to enable both manually, as the update procedure doesn't know whether you turned them off because you don't want them to run. Until both are enabled, you will not get valid information from wtmpdb.
Not really: wtmpdb will report correct entries for users, just boot/shutdown entries will be missing. And there is no cleanup function called, which makes sure, that the database does not grow too much (aka "logrotate for wtmpdb") 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it. So, is this being dealt with in a future update? -- Sincerely Kilian Hanich
On Wed, Jun 28, Kilian Hanich wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it.
So, is this being dealt with in a future update?
Until now nobody has an idea how to "fix" this with an update: it's no longer possible to distinguished between "not enabled because of the bug" and "not enabled because admin did disable it". 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Wed, Jun 28, Larry Len Rainey wrote:
Why only tumbleweed has wtmpdb installed and none of the leap from a 15.4 to 15.5 upgrades do and zypper in wmtpdb - says no provider of wtmpdb in leap.
How do I install it on leap or is it only Tumbleweed and micro?
This is the "factory" mailing list, so Tumbleweed, MicroOS, Aeon, Kalpa. Not Leap, as this is not factory. Leap 15.x will most likely never see it, Leap 16 (or whatever the name/version will be) should have it. Thorsten
On 6/28/23 09:49, Thorsten Kukuk wrote:
On Wed, Jun 28, Kilian Hanich wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it.
So, is this being dealt with in a future update?
Until now nobody has an idea how to "fix" this with an update: it's no longer possible to distinguished between "not enabled because of the bug" and "not enabled because admin did disable it".
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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Well, in this case we have a major problem because a lot of users will likely never notice. Although we could deal with this (and possible future accidents) via systemd.preset and calling systemctl preset $UNIT in the scriplets. Am 28.06.23 um 16:49 schrieb Thorsten Kukuk:
On Wed, Jun 28, Kilian Hanich wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it.
So, is this being dealt with in a future update?
Until now nobody has an idea how to "fix" this with an update: it's no longer possible to distinguished between "not enabled because of the bug" and "not enabled because admin did disable it".
Thorsten
-- Sincerely Kilian Hanich
On 28.06.2023 18:06, Kilian Hanich wrote:
Well, in this case we have a major problem because a lot of users will likely never notice.
This problem is years old, even before systemd started to use github issue tracker. So far nobody came up with a solution (at least, with an actual implementation of such solution).
Although we could deal with this (and possible future accidents) via systemd.preset and calling systemctl preset $UNIT in the scriplets.
Which is no solution because it ignores decision of local administrator.
Am 28.06.23 um 16:49 schrieb Thorsten Kukuk:
On Wed, Jun 28, Kilian Hanich wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it.
So, is this being dealt with in a future update?
Until now nobody has an idea how to "fix" this with an update: it's no longer possible to distinguished between "not enabled because of the bug" and "not enabled because admin did disable it".
Thorsten
-- Sincerely
Kilian Hanich
Am 28.06.23 um 21:41 schrieb Andrei Borzenkov:
Although we could deal with this (and possible future accidents) via systemd.preset and calling systemctl preset $UNIT in the scriplets.
Which is no solution because it ignores decision of local administrator.
From the systemd.preset manpage:
systemctl preset is used by the post install scriptlets of rpm packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy.
Administrators can overwrite distro policy by providing a preset file of higher priority. Additionally it would still be off if the administrator masked the service. -- Sincerely Kilian Hanich
Maybe I should go into more detail of why I consider it so much of a problem: At the core of Tumbleweed we always do distribution upgrades. This means we always do the same thing as what is being done if one would upgrade from Leap 14 to Leap 15 or from Leap 15.5 to Leap 15.6 and the like. The only real difference is that in our case the changes between dist-upgrades are considerably smaller since a lot of people do these on a daily basis. Some do it rarer (e.g. because they only use the device once a week). That means that unlike in between version jumps of regular release distros, we introduce even service changes quite a bit more often. Because of that we somehow need to make sure that the system works. Let's just imagine that at some point somebody comes around and creates a successor for DBus for whatever reason and systemd decides that they want to switch to it long term and after a few years of supporting both they drop the old. That means that at the point the old would be dropped, everybody's system, where it didn't work correctly or only half (in my case one of these two services were enabled and the other disabled), would suddenly break on a fundamental basis. Requiring people to look at a mailing list for that or do clean reinstalls is not a solution to this, it's a stop gap. So Let's actually look at what goes wrong here: Currently we rely on the order zypper upgrades the packages, which is not deterministic for (in zypper's eyes) unrelated packages. That's prone to break. And quite frankly, I don't think that this is even a bug on any packages side, but a bug in the way we try to maintain this distribution. There isn't a fix we can apply to a package for that, that's not possible. We can only apply a fix to the policy we have here. While you can maybe make the argument that this is just how it is and all Tumbleweed users need to follow news, make sure everything is fine and goes correctly and the like, other openSUSE distros like microOS and the like are intended to be fully automated in this aspect. They are explicitly intended that you don't need to do that. We are in a pretty interesting situation here because Arch just goes and pretty much says "you are in charge of enabling/disabling basically everything, we don't do anything like that" (that's also why some call it a DIY distro and they only provide a "disable *" preset file). Debian has it's deb-systemd-helper to deal with this stuff (it keeps track of enabled/disabled and can figure out if it was enabled/disabled by admin or not if the admin doesn't mess with it). Am 29.06.23 um 00:21 schrieb Kilian Hanich:
Am 28.06.23 um 21:41 schrieb Andrei Borzenkov:
Although we could deal with this (and possible future accidents) via systemd.preset and calling systemctl preset $UNIT in the scriplets.
Which is no solution because it ignores decision of local administrator.
From the systemd.preset manpage:
systemctl preset is used by the post install scriptlets of rpm packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy.
Administrators can overwrite distro policy by providing a preset file of higher priority.
Additionally it would still be off if the administrator masked the service.
-- Sincerely
Kilian Hanich
-- Sincerely Kilian Hanich
On Thu, Jun 29, Kilian Hanich wrote:
So Let's actually look at what goes wrong here:
Currently we rely on the order zypper upgrades the packages, which is not deterministic for (in zypper's eyes) unrelated packages. That's prone to break. And quite frankly, I don't think that this is even a bug on any packages side, but a bug in the way we try to maintain this distribution. There isn't a fix we can apply to a package for that, that's not possible. We can only apply a fix to the policy we have here.
No, this is not the case. We don't rely on the order zypper upgrades the packages. We have a package with some configuration files and scripts, which normally makes sure, that services are enabled if they should be, independent of the order in which zypper upgrades the packages. Somebody broke this script one year ago, so that it does not work anymore at all. That's bad, and even worse it, that either nobody noticed this, or nobody cared to report it as bug. That the services get enabled in some cases depending on the order in which zypper upgrades the packages is only by accident, not design, as we run now in another case in which other scripts still work. The big problem is: It's not only wtmpdb, but __ALL__ services added to the preset list during the last 12 month are most likely broken! And it's not that something is just not installed or so, but the result is a broken system, something, which happens from time to time with Tumbleweed, even if we have all the testing before we release a snapshot. But this testing cannot test every case.
While you can maybe make the argument that this is just how it is and all Tumbleweed users need to follow news, make sure everything is fine and goes correctly and the like, other openSUSE distros like microOS and the like are intended to be fully automated in this aspect. They are explicitly intended that you don't need to do that.
Correct, and every month again a bug slips through testing and get's released to the users. We had already more than once that users need to do a rollback manually of MicroOS to recover from this. We don't have the perfect 100% QA, and as result, bugs happen. That's unavoidable.
We are in a pretty interesting situation here because Arch just goes and pretty much says "you are in charge of enabling/disabling basically everything, we don't do anything like that" (that's also why some call it a DIY distro and they only provide a "disable *" preset file). Debian has it's deb-systemd-helper to deal with this stuff (it keeps track of enabled/disabled and can figure out if it was enabled/disabled by admin or not if the admin doesn't mess with it).
And we have systemd-preset-common-SUSE to do that, like Debian has deb-systemd-helper. And if Debians deb-systemd-helper gets broken, the result is the same as now, where systemd-preset-common-SUSE was broken for far too long. But you can complain as long and loud as you want: as long as nobody has an idea, how to identify all the "broken" services from the last 12 month and fix them, without breaking the system by accident (so make it worse then the current situation), we cannot "fix" it with an update. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Wednesday 2023-06-28 16:49, Thorsten Kukuk wrote:
On Wed, Jun 28, Kilian Hanich wrote:
IMPORTANT: please check that the wtmpdb-update-boot.service and wtmpdb-rotate.timer are enabled, if not, please enable them: systemctl enable --now wtmpdb-update-boot.service systemctl enable wtmpdb-rotate.timer
I would guess most users aren't subscribed to this mailing list and as such won't do this because they don't know about it.
So, is this being dealt with in a future update?
Until now nobody has an idea how to "fix" this with an update: it's no longer possible to distinguished between "not enabled because of the bug" and "not enabled because admin did disable it".
Use /usr/bin/last as a trigger that the admin wanted it: Make it a script which checks if the service thing/upgrade procedure is enabled/was done, and if not, warn about it, and steps to reenable (or maybe autoreenable at that point if root).
Hi Thorsten, On 6/28/23 10:40, Thorsten Kukuk wrote:
On openSUSE Tumbleweed/MicroOS/... we introduced meanwhile wtmpdb, which solves the Y2038 problem and some others, too. "wtmpdb last" should work already today and show you similar output compared with "last" itself. The next and final step will be, making "last" a link to "wtmpdb last" and rename the old last to "last.legacy". There are currently no plans to disable writing of wtmp entries completly, I expect that this will come most likely together with utmp. So the applications reading wtmp directly (currently I'm only aware of accounts-daemon, maybe samba, haven't analyzed that code yet) should continue to work. The other 99% of applications accessing wtmp do only create new entries, this should cause no issues.
The commands `users` and `who` from the coreutils package may use wtmp: $ users --help Usage: users [OPTION]... [FILE] Output who is currently logged in according to FILE. If FILE is not specified, use /var/run/utmp. /var/log/wtmp as FILE is common. [...] $ who --help Usage: who [OPTION]... [ FILE | ARG1 ARG2 ] Print information about users who are currently logged in. [...] If FILE is not specified, use /var/run/utmp. /var/log/wtmp as FILE is common. I'm not sure if those commands are used much with a FILE argument nowadays. Have a nice day, Berny
On 29/06/2023 00.45, Bernhard Voelker wrote:
The commands `users` and `who` from the coreutils package may use wtmp:
strace -e file who 2>&1 | grep tmp shows on Leap, that they both use /var/run/utmp while `last` and `lslogins` use /var/log/wtmp to have data from before the boot.
On Thu, Jun 29, Bernhard M. Wiedemann via openSUSE Factory wrote:
On 29/06/2023 00.45, Bernhard Voelker wrote:
The commands `users` and `who` from the coreutils package may use wtmp:
strace -e file who 2>&1 | grep tmp
shows on Leap, that they both use /var/run/utmp
while `last` and `lslogins` use /var/log/wtmp to have data from before the boot.
What he did mean was "strace -e file who /var/log/wtmp 2>&1 | grep tmp" execve("/usr/bin/who", ["who", "/var/log/wtmp"], 0x7fffb48358f8 /* 103 vars */) = 0 access("/var/log/wtmpx", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) openat(AT_FDCWD, "/var/log/wtmp", O_RDONLY|O_CLOEXEC) = 3 Only question is, why who tries to use /var/log/wtmpx if I specify /var/log/wtmp? Seems like a developer wanted to be too clever :( 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Jun 29 2023, Thorsten Kukuk wrote:
Only question is, why who tries to use /var/log/wtmpx if I specify /var/log/wtmp? Seems like a developer wanted to be too clever :(
https://repo.or.cz/glibc/history.git/commitdiff/d1dc3bdc5d -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Thu, Jun 29, Bernhard Voelker wrote:
Hi Thorsten,
On 6/28/23 10:40, Thorsten Kukuk wrote:
On openSUSE Tumbleweed/MicroOS/... we introduced meanwhile wtmpdb, which solves the Y2038 problem and some others, too. "wtmpdb last" should work already today and show you similar output compared with "last" itself. The next and final step will be, making "last" a link to "wtmpdb last" and rename the old last to "last.legacy". There are currently no plans to disable writing of wtmp entries completly, I expect that this will come most likely together with utmp. So the applications reading wtmp directly (currently I'm only aware of accounts-daemon, maybe samba, haven't analyzed that code yet) should continue to work. The other 99% of applications accessing wtmp do only create new entries, this should cause no issues.
The commands `users` and `who` from the coreutils package may use wtmp:
$ users --help Usage: users [OPTION]... [FILE] Output who is currently logged in according to FILE. If FILE is not specified, use /var/run/utmp. /var/log/wtmp as FILE is common. [...]
Yes, you can print on the screen, how often your account name is listed in /var/log/wtmp. It may have been usefull decades ago, when there were no tools like lastlog and last, but today it's pretty useless: # users /var/log/wtmp kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk kukuk root And is only possible since wtmp uses the same struct as utmp.
$ who --help Usage: who [OPTION]... [ FILE | ARG1 ARG2 ] Print information about users who are currently logged in.
[...] If FILE is not specified, use /var/run/utmp. /var/log/wtmp as FILE is common.
I'm not sure if those commands are used much with a FILE argument nowadays.
Same as users, in this case it gives you the same output as last. There are more tools which can read /var/log/wtmp because you can specify an alternate utmp file, so you could instead specify wtmp. This was discussed in several upstream projects (but not yet with coreutils, no time) and nobody could find a usefull use case. Reason is, that while the used struct is the same, the use case and content is completly different. But utmp will go away, too, there is no way around. First patches for coreutils to use logind instead of /run/utmp exist already: https://github.com/thkukuk/utmpx/tree/main/patches/coreutils So yes, admins, who wrote scripts 3-4 decades ago using this, needs to invest to "modernize" them and use current tools. As somebody wrote in a comment on lwn.net: it makes no sense to restrict Linux today just because 40 years ago there was an operating system with this restriction that nobody knows anymore. 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 Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
participants (14)
-
Andreas Schwab -
Andrei Borzenkov -
Bernhard M. Wiedemann -
Bernhard Voelker -
Felix Miata -
Jan Engelhardt -
Joe Salmeri -
Johannes Kastl -
Kilian Hanich -
Larry Len Rainey -
Nicolas FORMICHELLA -
Oliver Schwabedissen -
Simon Becherer -
Thorsten Kukuk