Restarting processes that use deleted files after updates

[Vahis]

Normally after updates I would restart some services that I think should
be restarted, some not, like some video or audio player.

Such processes can wait for the next time they will be started.

Often I just log out, go to init 3 and if that is not enough, I go to to
init 1 and then back to init 5

That procedure would most of the time clear everything out.

Now this time there was an update of glibc which is different.

My updates take place with this command in cron:

/usr/bin/zypper up -y -t patch --skip-interactive
--auto-agree-with-licenses

That command skips kernels, kernel would be interactive, requiring
reboot.

But glibc seems to require init to restart, that is to reboot.
I think there's no other way to restart init.

If I now go as root:
waxborg:~ # zypper ps
The following running processes use deleted files:

PID | PPID | UID | Login | Command | Service | Files
----+------+-----+-------+---------+---------+-----------------------
1 | 0 | 0 | root | init | | /lib64/libdl-2.11.3.so
| | | | | | /lib64/libc-2.11.3.so
| | | | | | /lib64/ld-2.11.3.so

OTOH as a user:

$ zypper ps
No processes using deleted files found.

So the question is:

Am I right in assuming that I can run the system as such for now
and when next reboot takes place the init will start using the new
files?

Nothing such was supposed to get updated that requires interaction, so
is it ok to continue running the system?

Or does zypper not respect the option '--skip-interactive'?
Would that be a bug?

Vahis
--
http://waxborg.servepics.com
openSUSE 11.4 (x86_64) 2.6.37.6-0.9-default main host
openSUSE 12.1 (x86_64) 3.1.1-48-desktop Tumbleweed in VirtualBox
openSUSE 12.1 (i586) 3.1.0-1.2-desktop in EeePC 900

[Eef Hartman]

Vahis <wax...@gmail.com.invalid> wrote:
> Now this time there was an update of glibc which is different.

Yeah, glibc is one of the updates that will require a full reboot to get
rid of all of the old daemons still using the _deleted_ libs.

> But glibc seems to require init to restart, that is to reboot.
> I think there's no other way to restart init.

The system will survive without reboot as the NEW applics will start using
the updated lib and the ones running still use the "in-memory" functions,
but a reboot is something to be scheduled "real soon now" indeed.

> PID | PPID | UID | Login | Command | Service | Files
> ----+------+-----+-------+---------+---------+-----------------------
> 1 | 0 | 0 | root | init | | /lib64/libdl-2.11.3.so
> | | | | | | /lib64/libc-2.11.3.so
> | | | | | | /lib64/ld-2.11.3.so

dl and libdl are the shared library loader system, part of glibc

> Am I right in assuming that I can run the system as such for now
> and when next reboot takes place the init will start using the new
> files?

Yes, but don't leave it TOO long, as soon as "newer" functions are loaded
into the RAM caches the system may get a bit instable.

> Or does zypper not respect the option '--skip-interactive'?
> Would that be a bug?

The problem is leaving out the libc update will disable all patches/updates
from then on as all those newer packages HAVE been build against the newer
libc, so NOT updating libc essentially means stopping updates altogether.
And the interface stays the same, so the older daemons DO run against the
newer libc, but because of caching you may wind up with a mix of older
and newer libc functions in memory.

I probably will schedule a reboot for all openSUSE systems here somewhere
during the weekend.

PS: with the newer kernel updating facilities in 12.1 even a kernel
update doesn't require a direct reboot anymore, as long as you keep
"running" kernel too.
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************

[Vahis]

On 2012-01-06, Eef Hartman <E.J.M....@tudelft.nl> wrote:
> Vahis <wax...@gmail.com.invalid> wrote:
>> Now this time there was an update of glibc which is different.
>
> Yeah, glibc is one of the updates that will require a full reboot to get
> rid of all of the old daemons still using the _deleted_ libs.
>

>> Am I right in assuming that I can run the system as such for now
>> and when next reboot takes place the init will start using the new
>> files?
>
> Yes, but don't leave it TOO long, as soon as "newer" functions are loaded
> into the RAM caches the system may get a bit instable.
>

> The problem is leaving out the libc update will disable all patches/updates
> from then on as all those newer packages HAVE been build against the newer
> libc, so NOT updating libc essentially means stopping updates altogether.

Then I think that it should not be updated if '--skip-interactive' is
chosen. Instead some notification in the system mail perhaps.

Thus the system could still be run and it would still be
stable, just no more updates.

This would give the admin more time to schedule the downtime better.

> I probably will schedule a reboot for all openSUSE systems here somewhere
> during the weekend.

Apparently there's no other way here either.

>
> PS: with the newer kernel updating facilities in 12.1 even a kernel
> update doesn't require a direct reboot anymore, as long as you keep
> "running" kernel too.

That's a good feature indeed. I have mine set that way.

The fact that 12.1/systemd lacks system mail altogether (without
additional steps) amazes me, it's crucial and systemd has already been
updated at least onece. No cure fot the mail yet though ;(

[Vahis]

On 2012-01-06, Eef Hartman <E.J.M....@tudelft.nl> wrote:

> Vahis <wax...@gmail.com.invalid> wrote:
>> Now this time there was an update of glibc which is different.
>
> Yeah, glibc is one of the updates that will require a full reboot to get
> rid of all of the old daemons still using the _deleted_ libs.
>

>> Am I right in assuming that I can run the system as such for now
>> and when next reboot takes place the init will start using the new
>> files?
>
> Yes, but don't leave it TOO long, as soon as "newer" functions are loaded
> into the RAM caches the system may get a bit instable.
>

> The problem is leaving out the libc update will disable all patches/updates
> from then on as all those newer packages HAVE been build against the newer
> libc, so NOT updating libc essentially means stopping updates altogether.

Then I think that it should not be updated if '--skip-interactive' is
chosen. Instead some notification in the system mail perhaps.

Thus the system could still be run and it would still be
stable, just no more updates.

This would give the admin more time to schedule the downtime better.

> I probably will schedule a reboot for all openSUSE systems here somewhere
> during the weekend.

Apparently there's no other way here either.

>
> PS: with the newer kernel updating facilities in 12.1 even a kernel
> update doesn't require a direct reboot anymore, as long as you keep
> "running" kernel too.

That's a good feature indeed. I have mine set that way.

The fact that 12.1/systemd lacks system mail altogether (without
additional steps) amazes me, it's crucial and systemd has already been

updated at least once. No cure for the mail yet though ;(

[Vahis]

On 2012-01-06, houghi <hou...@houghi.org.invalid> wrote:

> Vahis wrote:
>>> The problem is leaving out the libc update will disable all patches/updates
>>> from then on as all those newer packages HAVE been build against the newer
>>> libc, so NOT updating libc essentially means stopping updates altogether.
>>
>> Then I think that it should not be updated if '--skip-interactive' is

>> chosen. i
>
> Indeed. Bug report needed, I think.
>
Against zypper or glibc?

How does zypper know if a certain update needs interactive measures?

Should the package/patch tell this to zypper?
Does it but zypper can't handle it?

>> Instead some notification in the system mail perhaps.
>

> No. If you select to not have certain updates, I would not like to get
> mails that basicaly tell me 'Are you sure?'.

Normally I get mail when cron runs.
As for zypper the mail tells me which packages were updated,
in case of kernel it tells me it was skipped.

Most of the time I get "nothing to do"

I'm cool with those.

But it's not good to have the updates run and then to be told to restart
some processes including 'init'

>I have opted out and if
> things go wrong, please let me take the blame for it. I hate these kinds
> of 'reminders'.

If you don't want system mail, just use 12.1/systemd.
No system mail there...

Or maybe it's you I can thank for requesting this feature there ;)

[Vahis]

On 2012-01-06, houghi <hou...@houghi.org.invalid> wrote:
> Vahis wrote:
>>> Indeed. Bug report needed, I think.
>>>
>> Against zypper or glibc?
>>
>> How does zypper know if a certain update needs interactive measures?
>

> Zypper as it is an update issue.
>
This is my impression, too.

>> Should the package/patch tell this to zypper?
>> Does it but zypper can't handle it?
>

> No idea where it comes from. I believe there is info in the update that
> concerns this. Now if sypper people say this it should be handled by the
> glibc people, then they will forward it and tell them to include
> whatever zypper needs.

OK.

>
>> Normally I get mail when cron runs.
>> As for zypper the mail tells me which packages were updated,
>> in case of kernel it tells me it was skipped.
>

> That is a seperate issue. That is the handling of what you do in
> general. I set it to not send me anything in those cases. I would hate
> it to get message sthat would say 'hey I did an update, but I did not
> update XYZ'

I want this information.
I want everything automated as much as possible.
So when no intervention is needed the system gets updated without a
touch of a finger.

But like kernel or glibc I want to know about them.
Then I can schedule the updates at a proper time.

>
>> If you don't want system mail, just use 12.1/systemd.
>> No system mail there...
>>
>> Or maybe it's you I can thank for requesting this feature there ;)
>

> Nope, it isn't.

Joke :)

But seriously, for me it's a show stopper.
I know some stuff that doesn't work in 12.1/systemd.

But I don't know what else there might be.

So 12.1 stays in VM and in a non important gadget.
It has no business in "production" here any time soon.

And when I look at the mailing list there's no development discussion,
just arguing in favor and against systemd.

[Vahis]

On 2012-01-06, houghi <hou...@houghi.org.invalid> wrote:
> Vahis wrote:

>>> The problem is leaving out the libc update will disable all patches/updates
>>> from then on as all those newer packages HAVE been build against the newer
>>> libc, so NOT updating libc essentially means stopping updates altogether.
>>
>> Then I think that it should not be updated if '--skip-interactive' is

>> chosen. i

>
> Indeed. Bug report needed, I think.

Bug #730959
It was there already, about kernel update.
I commented about glibc and gave my votes.

[Vahis]

On 2012-01-06, houghi <hou...@houghi.org.invalid> wrote:
> Vahis wrote:
>> I want this information.
>> I want everything automated as much as possible.
>> So when no intervention is needed the system gets updated without a
>> touch of a finger.
>>
>> But like kernel or glibc I want to know about them.
>> Then I can schedule the updates at a proper time.
>

> That is what the security update mailinglist is for.

True. But often the mailing lists announce updates that already sneaked to
my machine.

I want is automatic updates and '--skip-interactive to work'

>
>> And when I look at the mailing list there's no development discussion,
>> just arguing in favor and against systemd.
>

> I can understand that. Change is always reluctant.

I'm not against systemd. How could I?
I know nothing about it.
But I'm against forcing broken software into my systems.

>I have not even tried
> to look what happens if I go back. The major issue I notice is that I
> don't see what gets started at the beginning.

We used to have commands like 'init 1' and 'init 5 & exit'
Try that now.

OTOH the cure for network troubles was just a while ago:"Disable IPv6"
Now IPv6 works and there's no reason to disable it, on the contrary.

So obviously running 12.1 and Tumbleweed, both with systemd will get
better. In the meantime I'll keep the sandboxed in VM's.

[Vahis]

On 2012-01-06, houghi <hou...@houghi.org.invalid> wrote:

> houghi wrote:
>>>> to look what happens if I go back. The major issue I notice is that I
>>>> don't see what gets started at the beginning.
>>>
>>> We used to have commands like 'init 1' and 'init 5 & exit'
>>> Try that now.
>>

>> OK. Will do that after this posting.
>
> So I did the following:
> * [CTRL][ALT][F1]
> * Log in a root
> * Type `init 3`
>
> Result: The movie that was playing on tty7 in GUI stopped as excpected.
> No more tty7 or GUI running. I then did the following:
>
> * init 5 && exit
> The result was that the GUI came up and all ran as expected¹.

That is how it has always worked.
SIW with systemd and init 3.

But how does one get to init _1_ and _back?_

[Aragorn]

On Sunday 08 January 2012 19:47, houghi conveyed the following to
alt.os.linux.suse...

> Vahis wrote:
>
>> But how does one get to init _1_ and _back?_
>

> init 3 or init 5.
>
> I have done it before. Can't test it now as I went back to the old
> system of booting.

Fortunately, openSUSE still gives you that choice (and tells you /how/
to do it too). Most other distributions follow RedHat's "do or die"
dictatorship in that and force systemd down your throat.

> There I can see what I want to see and postfix and
> cron work for me. As I have done 0 (zero) problem solving I have no
> idea why it did not work, other then that it _perhaps_ was linked to
> the mounting of /var.

You could be on to something there. From what I've read, it would
appear as if "/var/lock" and "/var/run" are now both needed at boot time
as a dependency of udev and/or systemd.

--
= Aragorn =
(registered GNU/Linux user #223157)