[opensuse-factory] TW 20170626: /var/lock gone?
Hi List, did an update to TW 20170626 yesterday evening. Today I got a mail from a failed cron job that SCRIPT: mlocate.cron exited with RETURNCODE = 1. SCRIPT: output (stdout && stderr) follows touch: cannot touch '/var/lock/mlocate.daily.lock': No such file or directory Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 30, Peter Suetterlin wrote:
Hi List,
did an update to TW 20170626 yesterday evening. Today I got a mail from a failed cron job that
SCRIPT: mlocate.cron exited with RETURNCODE = 1. SCRIPT: output (stdout && stderr) follows
touch: cannot touch '/var/lock/mlocate.daily.lock': No such file or directory
Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update....
filesystem should and still does create the link /var/lock to /run/lock, and systemd does so, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
filesystem should and still does create the link /var/lock to /run/lock, and systemd does so, too.
Looks it didn't create it here when installing the rpm, and I haven't rebooted since. Delayed delete maybe? That the script still saw it, from a busy file in there? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Thorsten Kukuk <kukuk@suse.de> [06-30-17 08:03]:
On Fri, Jun 30, Peter Suetterlin wrote:
Hi List,
did an update to TW 20170626 yesterday evening. Today I got a mail from a failed cron job that
SCRIPT: mlocate.cron exited with RETURNCODE = 1. SCRIPT: output (stdout && stderr) follows
touch: cannot touch '/var/lock/mlocate.daily.lock': No such file or directory
Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update....
filesystem should and still does create the link /var/lock to /run/lock, and systemd does so, too.
maybe it should and maybe "for you" it still does, but some condition is causing it to "sometimes" not create the link. I had it on two machines in the last few days and created the link manually bypassing the problem, ln -s ../run/lock /var/lock -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Peter Suetterlin wrote:
Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update....
To be more specific, before: woodstock:/ # rpm -qf /var/lock filesystem-13.3-15.1.x86_64 after: woodstock:/var # rpm -qf /var/lock file /var/lock is not owned by any package rpm -ql filesystem |grep lock gives no match -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2017-06-30 at 13:01 +0100, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update....
To be more specific, before:
woodstock:/ # rpm -qf /var/lock filesystem-13.3-15.1.x86_64
after:
woodstock:/var # rpm -qf /var/lock file /var/lock is not owned by any package
rpm -ql filesystem |grep lock gives no match
/var/lock should be a symlink to /run/lock and the entire construct is managed by systemd-tmpfiles, base don /usr/lib/tmpfiles.d/legacy.conf: d /run/lock 0775 root lock - L /var/lock - - - - ../run/lock systemd-tmpfiles --create /usr/lib/tmpfiles.d/legacy.conf should take care of this setup - and this should actually run at every boot; did you restart your TW machine after applying the update? Cheers, Dominique
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [06-30-17 08:17]:
On Fri, 2017-06-30 at 13:01 +0100, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Indeed there is no more /var/lock, snapper pre/post diff shows it was deleted during the update....
To be more specific, before:
woodstock:/ # rpm -qf /var/lock filesystem-13.3-15.1.x86_64
after:
woodstock:/var # rpm -qf /var/lock file /var/lock is not owned by any package
rpm -ql filesystem |grep lock gives no match
/var/lock should be a symlink to /run/lock and the entire construct is managed by systemd-tmpfiles, base don /usr/lib/tmpfiles.d/legacy.conf:
d /run/lock 0775 root lock - L /var/lock - - - - ../run/lock
systemd-tmpfiles --create /usr/lib/tmpfiles.d/legacy.conf
should take care of this setup - and this should actually run at every boot; did you restart your TW machine after applying the update?
I did not and usually only reboot for a new kernel or when restarting dbus is necessary. are you saying there is now another requirement to reboot a system? and this was not required previously? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2017-06-30 at 08:20 -0400, Patrick Shanahan wrote:
I did not and usually only reboot for a new kernel or when restarting dbus is necessary. are you saying there is now another requirement to reboot a system? and this was not required previously?
I'm not saying a reboot is required after every TW upgrade - and I'm also not working towards the goal that this would become a nescessity. But in this case I can well see that filesystem removed a link that was in place before and no other package came 'after' to take care of putting it back in place again. Cheers, Dominique
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [06-30-17 08:25]:
On Fri, 2017-06-30 at 08:20 -0400, Patrick Shanahan wrote:
I did not and usually only reboot for a new kernel or when restarting dbus is necessary. are you saying there is now another requirement to reboot a system? and this was not required previously?
I'm not saying a reboot is required after every TW upgrade - and I'm also not working towards the goal that this would become a nescessity. But in this case I can well see that filesystem removed a link that was in place before and no other package came 'after' to take care of putting it back in place again.
tks, I'm wondering why it *just* became necessary as this is the first time I have had to recreate the link, and I sometimes go days with running processes using deleted files. but I probably should not update as frequently as I do :(. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2017-06-30 at 08:30 -0400, Patrick Shanahan wrote:
tks, I'm wondering why it *just* became necessary as this is the first time I have had to recreate the link, and I sometimes go days with running processes using deleted files. but I probably should not update as frequently as I do :(.
It's because filesystem 'dropped' owning this link which made no sense to be with it. filesystem has a %pre script to link /var/lock to /run/locm, but that runs BEFORE filesystem is being updated, so the order did not catch here: * old filesystem package owned /var/lock * new package's pre script ran, ensuring the link is in place if /var/lock would be missing * new filesytem package was installed (not owning /var/lock) * old filesystem is being uninstalled, no longer owned files and directories being removed (hence, /var/lock symlink being deleted as no rpm is left registered as owner) => this is the situation that brough you to the current situation. The only way I can see to remediate this would be to also have a %post script in filesystem to address this special case - but I'm not sure it's really worth it Cheers, Dominique
Dominique Leuenberger / DimStar wrote:
* old filesystem package owned /var/lock * new package's pre script ran, ensuring the link is in place if /var/lock would be missing * new filesytem package was installed (not owning /var/lock) * old filesystem is being uninstalled, no longer owned files and directories being removed (hence, /var/lock symlink being deleted as no rpm is left registered as owner)
Ah, that makes sense indeed.
=> this is the situation that brough you to the current situation. The only way I can see to remediate this would be to also have a %post script in filesystem to address this special case - but I'm not sure it's really worth it
It wouldn't cost much to add it, but prevent some head scratching. If a similar change happens on a less-fast changing distribution than TW it is very likely that there won't be a reboot for quite some time, and a missing /var/lock can mess up quite some things... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 30, 2017 at 02:10:00PM +0100, Peter Suetterlin wrote:
Dominique Leuenberger / DimStar wrote:
=> this is the situation that brough you to the current situation. The only way I can see to remediate this would be to also have a %post script in filesystem to address this special case - but I'm not sure it's really worth it
It wouldn't cost much to add it, but prevent some head scratching.
It also wouldn't work because the uninstall of the old package is done after the install of the new package. You'll need a posttrans script to make it work. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
30.06.2017 17:57, Michael Schroeder пишет:
On Fri, Jun 30, 2017 at 02:10:00PM +0100, Peter Suetterlin wrote:
Dominique Leuenberger / DimStar wrote:
=> this is the situation that brough you to the current situation. The only way I can see to remediate this would be to also have a %post script in filesystem to address this special case - but I'm not sure it's really worth it
It wouldn't cost much to add it, but prevent some head scratching.
It also wouldn't work because the uninstall of the old package is done after the install of the new package. You'll need a posttrans script to make it work.
%filetriggerpostun in new package ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30/06/17 08:30 AM, Patrick Shanahan wrote:
tks, I'm wondering why it *just* became necessary as this is the first time I have had to recreate the link, and I sometimes go days with running processes using deleted files. but I probably should not update as frequently as I do :(.
Indeed. It looks to me like there should have been a command executed after, an option on 'systemd-tmpfiles' (see man page), that recreated the directory. No need for reboot. -- Democracy does not guarantee equality of conditions; it only guarantees equality of opportunity. --Irving Kristol -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger / DimStar wrote:
/var/lock should be a symlink to /run/lock and the entire construct is managed by systemd-tmpfiles, base don /usr/lib/tmpfiles.d/legacy.conf:
I know what it's supposed to be pointing at, and created the link myself.
systemd-tmpfiles --create /usr/lib/tmpfiles.d/legacy.conf
Maybe that one should go in the postinstall script of filesystem then? But my suspicion (see other post) is that the removal of /var/lock had been delayed because it was still in use, so the post-script did not do anything, and after the handle was free the link got deleted?
should take care of this setup - and this should actually run at every boot; did you restart your TW machine after applying the update?
No, not yet; and I hope noone expects to reboot after such a minor package change... (the filesystem package, not the whole update as such) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 30, Peter Suetterlin wrote:
Dominique Leuenberger / DimStar wrote:
/var/lock should be a symlink to /run/lock and the entire construct is managed by systemd-tmpfiles, base don /usr/lib/tmpfiles.d/legacy.conf:
I know what it's supposed to be pointing at, and created the link myself.
systemd-tmpfiles --create /usr/lib/tmpfiles.d/legacy.conf
Maybe that one should go in the postinstall script of filesystem then?
No, clearly not. Else you will no longer be able to install tumbleweed correct.
But my suspicion (see other post) is that the removal of /var/lock had been delayed because it was still in use, so the post-script did not do anything, and after the handle was free the link got deleted?
I think creating the symlink should be a %posttrans, not a %pretrans. The way it is in filesystem package looks wrong to me. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2017-06-30 at 15:25 +0200, Thorsten Kukuk wrote:
But my suspicion (see other post) is that the removal of /var/lock
had been delayed because it was still in use, so the post-script did not do anything, and after the handle was free the link got deleted?
I think creating the symlink should be a %posttrans, not a %pretrans. The way it is in filesystem package looks wrong to me.
Thorsten
I wonder if we should not rather do %post than %posttrans when we change it. In context of zypper, the difference is 'small' (in any case, each package is installed as a transaction of its own) - but zypp will install the packages and skip/collect transaction scripts in order to execute them in the end. If we have anything in the larger install chain expecting /var/lock, we might run into some other strange issues there. Cheers, Dominique
On Fri, Jun 30, Dominique Leuenberger / DimStar wrote:
I wonder if we should not rather do %post than %posttrans when we change it. In context of zypper, the difference is 'small' (in any case, each package is installed as a transaction of its own) - but zypp will install the packages and skip/collect transaction scripts in order to execute them in the end.
Depends on from where you are coming. If /var/lock is still a directory, %post will not work. The directory is only removed afterwards I was told. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2017-06-30 at 16:38 +0200, Thorsten Kukuk wrote:
On Fri, Jun 30, Dominique Leuenberger / DimStar wrote:
I wonder if we should not rather do %post than %posttrans when we change it. In context of zypper, the difference is 'small' (in any case, each package is installed as a transaction of its own) - but zypp will install the packages and skip/collect transaction scripts in order to execute them in the end.
Depends on from where you are coming. If /var/lock is still a directory, %post will not work. The directory is only removed afterwards I was told.
Thorsten
ah right... taking into account the ordering, this is true: 1. %pretrans of new package 2. %pre of new package 3. package install 4. %post of new package 5. %triggerin of other packages (set off by installing new package) 6. %triggerin of new package (if any are true) 7. %triggerun of old package (if it's set off by uninstalling the old package) 8. %triggerun of other packages (set off by uninstalling old package) 9. %preun of old package 10. (removal of old package) 11. %postun of old package 12. %triggerpostun of old package (if it's set off by uninstalling the old package) 13. %triggerpostun of other packages (if they're setu off by uninstalling the old package) 14. %posttrans of new package so %post in the new package is definitively too early, as the old package is not yet uninstalled - and /var/lock thus still present That means posttrans would be an option (with the issue I already stated - other packages upgrading in the same transaction might not have /var/lock available, or possibly a triggerpostun -- filesystem might work as well (I recall having seen such a hack already somewhere) Cheers, Dominique
On Fri, Jun 30, Peter Suetterlin wrote:
To be more specific, before:
woodstock:/ # rpm -qf /var/lock filesystem-13.3-15.1.x86_64
after:
woodstock:/var # rpm -qf /var/lock file /var/lock is not owned by any package
rpm -ql filesystem |grep lock gives no match
Correct, the OBS checks don't allow a symlink to a file not yet there (/run/lock), and we cannot package /run/lock because it's dynamic created by systemd and contains special ownership, which creates a funny, not always solved correctly dependency cycle. Beside that three package did create /var/lock in the past ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Andrei Borzenkov -
Anton Aylward -
Dominique Leuenberger / DimStar -
Michael Schroeder -
Patrick Shanahan -
Peter Suetterlin -
Thorsten Kukuk