I have noticed over the last few days that whenever one of our openSUSE 15.2 systems is rebooted, /var/lock/subsys disappears. Since we have applications that use it, I have been manually putting it back, but I'm curious as to why it goes missing. Does anyone know? JY "All ideas and opinions expressed in this communication are those of the author alone and do not necessarily reflect the ideas and opinions of anyone else."
John Young wrote:
I have noticed over the last few days that whenever one of our openSUSE 15.2 systems is rebooted, /var/lock/subsys disappears. Since we have applications that use it, I have been manually putting it back, but I'm curious as to why it goes missing.
/var/lock symlinks to /run/lock and /run is a tmpfs. Maybe the question is what creates /var/lock/subsys and/or why it isn't doing it anymore? Interestingly, on a 15.2 system I am just working on, it is also missing. -- Per Jessen, Zürich (22.6°C)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2021-04-01 at 18:04 +0200, Per Jessen wrote:
John Young wrote:
I have noticed over the last few days that whenever one of our openSUSE 15.2 systems is rebooted, /var/lock/subsys disappears. Since we have applications that use it, I have been manually putting it back, but I'm curious as to why it goes missing.
/var/lock symlinks to /run/lock and /run is a tmpfs. Maybe the question is what creates /var/lock/subsys and/or why it isn't doing it anymore?
Interestingly, on a 15.2 system I am just working on, it is also missing.
I have it. cer@Telcontar:~> ll /var/lock lrwxrwxrwx 1 root root 11 Jan 1 12:16 /var/lock -> ../run/lock cer@Telcontar:~> cer@Telcontar:~> rpm -qf /var/lock file /var/lock is not owned by any package cer@Telcontar:~> The creation date is interesting to me. cer@Telcontar:~> ll --full-time /var/lock lrwxrwxrwx 1 root root 11 2021-01-01 12:16:28.082749593 +0100 /var/lock -> ../run/lock cer@Telcontar:~> Nothing was installed that instant: cer@Telcontar:~> rpm -qa --last ... virtualbox-kmp-default-6.1.16_k5.3.18_lp152.57-lp152.2.8.1.x86_64 2021-01-01T13:18:07 CET patterns-xfce-xfce_office-20190809-lp152.1.1.x86_64 2021-01-01T01:37:00 CET patterns-xfce-xfce-20190809-lp152.1.1.x86_64 2021-01-01T01:37:00 CET Ah, I found out: it was just when I upgraded from 15.1 to 15.2 (yes, I have a log for that). The system was first booted 2021-01-01 12:18:10, so it happened during the upgrade. As there are no upgrade entries in /var/log/messages-20210102.xz, it was not "zypper dup", but the DVD upgrade method. The oldest YaST log entries (/var/log/YaST2/y2log-9.gz) are dated 2021-01-01 13:18:13, so the pertinent entries were lost. Ah, wait, I have a backup. Argh! It is y2log-5.gz, written "Jan 1 13:18", but: 2020-12-26 12:41:22 <1> Telcontar(7011) [Y2Ruby] binary/YRuby.cc(~YRuby):117 Shutting down ruby interpreter. 2021-01-01 13:01:19 <1> Telcontar(31825) [Ruby] bin/y2start:22 y2base called with ["sw_single", "qt", "-name", "YaST2", "-icon", "yast"] the entries for the upgrade itself are missing, it appears the DVD doesn't write its log to disk. I thought it wrote at the end, on success. Missing feature. Sorry, I can't find what rpm script wrote the directory symlink /var/lock/ On another computer the date is more interesting: Isengard:/var/log # ll --full-time /var/lock lrwxrwxrwx 1 root root 11 2018-11-04 14:04:37.964558393 +0100 /var/lock -> ../run/lock 2018-11-04 12:02:24+01:00 - Booting the system now ================================================================================ LinuxIsengard 4.4.159-73-default #1 SMP Wed Oct 10 14:36:27 UTC 2018 (1f84342) x86_64 x86_64 x86_64 GNU/Linux 2018-11-04 14:47:30+01:00 - Halting the system now =========================================== uptime: 14:47:30 up 2:45, 0 users, load average: 0.69, 0.66, 1.27 2018-11-04 14:48:59+01:00 - Booting the system now ================================================================================ LinuxIsengard 4.12.14-lp150.12.22-default #1 SMP Sat Oct 13 05:05:16 UTC 2018 (09415e8) x86_64 x86_64 x86_64 GNU/Linux Wait, look at the kernel versions: Linux Isengard 4.4.159-73-default #1 SMP was upgraded to: Linux Isengard 4.12.14-lp150.12.22-default #1 SMP Which means that /var/lock/ was written during the upgrade of Leap 42.3 to Leap 15.0 - maybe I have the log. That upgrade was done via zypper dup and I do have the log entries (messages-20181110.xz): <1.5> 2018-11-04T14:04:36.032864+01:00 Isengard RPM - - Transaction ID 5bdeee64 finished: 0 <1.5> 2018-11-04T14:04:36.170291+01:00 Isengard RPM - - Transaction ID 5bdeee64 started <1.5> 2018-11-04T14:04:36.583883+01:00 Isengard RPM - - erase systemd-228-59.1.x86_64: success <3.5> 2018-11-04T14:04:36.645411+01:00 Isengard dbus 1222 - - [system] Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses <3.5> 2018-11-04T14:04:36.646761+01:00 Isengard dbus 1222 - - message repeated 3 times: [ [system] Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses] <3.6> 2018-11-04T14:04:36.647148+01:00 Isengard dbus-daemon 1222 - - Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses <3.6> 2018-11-04T14:04:36.648436+01:00 Isengard dbus-daemon 1222 - - message repeated 3 times: [ Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses] <3.5> 2018-11-04T14:04:37.253940+01:00 Isengard dbus 1222 - - [system] Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses <3.5> 2018-11-04T14:04:37.258628+01:00 Isengard dbus 1222 - - message repeated 12 times: [ [system] Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses] <3.6> 2018-11-04T14:04:37.259045+01:00 Isengard dbus-daemon 1222 - - Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses <3.6> 2018-11-04T14:04:37.265047+01:00 Isengard dbus-daemon 1222 - - message repeated 12 times: [ Unable to reload configuration: Configuration file needs one or more <listen> elements giving addresses] <3.6> 2018-11-04T14:04:37.499521+01:00 Isengard systemd-sysusers 17141 - - Creating group systemd-coredump with gid 468. <3.6> 2018-11-04T14:04:37.503582+01:00 Isengard systemd-sysusers 17141 - - Creating user systemd-coredump (systemd Core Dumper) with uid 468 and gid 468. <3.5> 2018-11-04T14:04:37.505334+01:00 Isengard nscd - - - 9608 ignored inotify event for `/etc/group` (file exists) <10.5> 2018-11-04T14:04:37.533804+01:00 Isengard polkitd 1314 - - Reloading rules <10.5> 2018-11-04T14:04:37.534538+01:00 Isengard polkitd 1314 - - Collecting garbage unconditionally... <10.5> 2018-11-04T14:04:37.538893+01:00 Isengard polkitd 1314 - - Loading rules from directory /etc/polkit-1/rules.d <10.5> 2018-11-04T14:04:37.540389+01:00 Isengard polkitd 1314 - - Loading rules from directory /usr/share/polkit-1/rules.d <3.5> 2018-11-04T14:04:37.544666+01:00 Isengard systemd 1 - - Reexecuting. <10.5> 2018-11-04T14:04:37.545329+01:00 Isengard polkitd 1314 - - Finished loading, compiling and executing 3 rules <10.5> 2018-11-04T14:04:37.545987+01:00 Isengard polkitd 1314 - - Reloading rules <10.5> 2018-11-04T14:04:37.548063+01:00 Isengard polkitd 1314 - - Collecting garbage unconditionally... <10.5> 2018-11-04T14:04:37.548495+01:00 Isengard polkitd 1314 - - Loading rules from directory /etc/polkit-1/rules.d <10.5> 2018-11-04T14:04:37.548942+01:00 Isengard polkitd 1314 - - Loading rules from directory /usr/share/polkit-1/rules.d <10.5> 2018-11-04T14:04:37.550195+01:00 Isengard polkitd 1314 - - Finished loading, compiling and executing 3 rules <3.6> 2018-11-04T14:04:37.688439+01:00 Isengard systemd 1 - - systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid) <3.6> 2018-11-04T14:04:37.703747+01:00 Isengard systemd 1 - - Detected architecture x86-64. <3.4> 2018-11-04T14:04:37.795420+01:00 Isengard systemd 1 - - nss-lookup.target: Dependency Before=nss-lookup.target dropped <3.5> 2018-11-04T14:04:37.866650+01:00 Isengard systemd 1 - - Unknown serialization item 'ready-sent=yes' <3.5> 2018-11-04T14:04:37.962955+01:00 Isengard systemd-tmpfiles 17163 - - [/usr/lib/tmpfiles.d/tmp.conf:13] Duplicate line for path "/var/tmp", ignoring. <3.5> 2018-11-04T14:04:37.963693+01:00 Isengard systemd-tmpfiles 17163 - - [/usr/lib/tmpfiles.d/var.conf:21] Duplicate line for path "/var/lib", ignoring. * <3.5> 2018-11-04T14:04:37.964181+01:00 Isengard systemd-tmpfiles 17163 - - [/usr/lib/tmpfiles.d/var.conf:23] Duplicate line for path "/var/spool", ignoring. <1.5> 2018-11-04T14:04:38.091646+01:00 Isengard RPM - - install systemd-234-lp150.20.6.1.x86_64: success The timestamp of interest is "2018-11-04 14:04:37.964558393", marked with "*" in that paragraph. The upgrade of systemd did it. :-D I even have the previous backup, so I can look up the "/var/lock" directory or link. It was a link on leap 42.3: lrwxrwxrwx 1 root root 9 2016-11-26 23:25:54.043947586 +0100 lock -> /run/lock I believe that was the creation date of that machine, because first boot in the log was on "2016-11-27 23:38:32+01:00". - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYGYQwRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV/xEAoIji3syRvRsqLuPv6LLM o4sfvGt/AJ9r1iiOjkbElQAluGGXz1G1lnODHQ== =qfJq -----END PGP SIGNATURE-----
On Thu, 1 Apr 2021 20:28:17 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2021-04-01 at 18:04 +0200, Per Jessen wrote:
John Young wrote:
I have noticed over the last few days that whenever one of our openSUSE 15.2 systems is rebooted, /var/lock/subsys disappears. Since we have applications that use it, I have been manually putting it back, but I'm curious as to why it goes missing.
/var/lock symlinks to /run/lock and /run is a tmpfs. Maybe the question is what creates /var/lock/subsys and/or why it isn't doing it anymore?
Interestingly, on a 15.2 system I am just working on, it is also missing.
I have it.
cer@Telcontar:~> ll /var/lock lrwxrwxrwx 1 root root 11 Jan 1 12:16 /var/lock -> ../run/lock cer@Telcontar:~>
What do you mean by 'it'? Per and John are talking about /var/lock/subsys/ whilst you seem to be talking about /var/lock/
On 01/04/2021 21.10, Dave Howorth wrote:
On Thu, 1 Apr 2021 20:28:17 +0200 (CEST) "Carlos E. R." <> wrote:
On Thursday, 2021-04-01 at 18:04 +0200, Per Jessen wrote:
John Young wrote:
I have noticed over the last few days that whenever one of our openSUSE 15.2 systems is rebooted, /var/lock/subsys disappears. Since we have applications that use it, I have been manually putting it back, but I'm curious as to why it goes missing.
/var/lock symlinks to /run/lock and /run is a tmpfs. Maybe the question is what creates /var/lock/subsys and/or why it isn't doing it anymore?
Interestingly, on a 15.2 system I am just working on, it is also missing.
I have it.
cer@Telcontar:~> ll /var/lock lrwxrwxrwx 1 root root 11 Jan 1 12:16 /var/lock -> ../run/lock cer@Telcontar:~>
What do you mean by 'it'?
Per and John are talking about /var/lock/subsys/ whilst you seem to be talking about /var/lock/
Sorry, I interpreted the "var/lock/" subsys. I do have " /var/lock/subsys" in one machine, not on another: Isengard:~ # ll /var/lock/ total 4 -rw-r--r-- 1 root root 22 Feb 27 03:56 asound.state.lock drwx------ 2 root root 40 Mar 14 19:50 dmraid drwx------ 2 root root 40 Feb 27 03:56 lvm drwxr-xr-x 2 root root 40 Feb 27 03:56 subsys Isengard:~ # Means it was created on boot. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (4)
-
Carlos E. R. -
Dave Howorth -
John Young -
Per Jessen