10:59 a.m.
It is common knowledge that one does not need to reboot for updates to take
effect in GNU Linux.
However, in actual practice, this is not so. I could cite many examples, but
this should suffice:
On Sunday evening, I installed a new updates-testing version of mesa and then I
suspended the machine for the night. The following Monday morning (yesterday),
I resumed the machine and suspended it again around noon. I again resumed the
machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An
hour or two after that, I powered it back up and the mesa testing update turned
out to be bad and I was not able to log in. I did not know which program was at
fault, because the bad program had been installed over 24 hours prior, but was
only showing itself to be bad after a power off.
Could someone explain how reboots are not needed in Linux for updates to
_take_, given the evidence to the contrary.
4:11 p.m.
On 07/05/2011 08:50 PM, Patrick O'Callaghan wrote:
On Tue, 2011-07-05 at 19:37 +0000, Beartooth wrote:
> On Thu, 30 Jun 2011 12:57:44 +0100, Bryn M. Reeves wrote:
>
>> On 06/30/2011 01:31 AM, Patrick O'Callaghan wrote:
> [....]
>>> It's a secret :-) Seriously, I noticed it maybe a year or so ago and
>>> have mentioned it several times on this and other lists, but it's still
>>> not well-known. It certainly didn't exist 13 years ago. The earliest
>>> reference I can see in a quick Google is early 2010 (F12).
>
>> $ rpm -q --changelog yum-utils | grep -C1 needs-restarting * Wed Nov 04
>> 2009 Seth Vidal <skvidal at fedoraproject.org> - add needs-restarting
>>
>> I noticed it had appeared in yum-utils some time in the last year or so
>> - yum-utils is one of those packages that I infrequently do a rpm -ql
>> yum-utils | grep bin for in case anything new has popped up - I think
>> it's also been mentioned on the list a few times.
>
> Oh good: if it's in yum-utils I have it on all machines. So does
> it run itself, like at least some of the other things in that package? Or
> should I be invoking it on occasion?
You run it yourself from a Shell. I don't know if any of the magic
package UI stuff also does this, but I don't use any of that.
The desktop PackageKit stuff should handle this itself (I don't think it calls
out to the script - see the backends for the different update management tools.
I think pkcon will notify you of this from the command line if you use it to
install updates rather than running yum directly.
Regards,
Bryn.
3:50 p.m.
On 07/05/2011 08:37 PM, Beartooth wrote:
On Thu, 30 Jun 2011 12:57:44 +0100, Bryn M. Reeves wrote:
> On 06/30/2011 01:31 AM, Patrick O'Callaghan wrote:
[....]
>> It's a secret :-) Seriously, I noticed it maybe a year or so ago and
>> have mentioned it several times on this and other lists, but it's still
>> not well-known. It certainly didn't exist 13 years ago. The earliest
>> reference I can see in a quick Google is early 2010 (F12).
> $ rpm -q --changelog yum-utils | grep -C1 needs-restarting * Wed Nov 04
> 2009 Seth Vidal <skvidal at fedoraproject.org> - add needs-restarting
>
> I noticed it had appeared in yum-utils some time in the last year or so
> - yum-utils is one of those packages that I infrequently do a rpm -ql
> yum-utils | grep bin for in case anything new has popped up - I think
> it's also been mentioned on the list a few times.
Oh good: if it's in yum-utils I have it on all machines. So does
it run itself, like at least some of the other things in that package? Or
should I be invoking it on occasion?
Afaik this one needs running by hand right now - although it doesn't seem like
it would be too much work to have it run automatically at the end of a yum update.
Cheers,
Bryn.
2:50 p.m.
On Tue, 2011-07-05 at 19:37 +0000, Beartooth wrote:
On Thu, 30 Jun 2011 12:57:44 +0100, Bryn M. Reeves wrote:
> On 06/30/2011 01:31 AM, Patrick O'Callaghan wrote:
[....]
>> It's a secret :-) Seriously, I noticed it maybe a year or so ago and
>> have mentioned it several times on this and other lists, but it's still
>> not well-known. It certainly didn't exist 13 years ago. The earliest
>> reference I can see in a quick Google is early 2010 (F12).
> $ rpm -q --changelog yum-utils | grep -C1 needs-restarting * Wed Nov 04
> 2009 Seth Vidal <skvidal at fedoraproject.org> - add needs-restarting
>
> I noticed it had appeared in yum-utils some time in the last year or so
> - yum-utils is one of those packages that I infrequently do a rpm -ql
> yum-utils | grep bin for in case anything new has popped up - I think
> it's also been mentioned on the list a few times.
Oh good: if it's in yum-utils I have it on all machines. So does
it run itself, like at least some of the other things in that package? Or
should I be invoking it on occasion?
You run it yourself from a Shell. I don't know if any of the magic
package UI stuff also does this, but I don't use any of that.
poc
2:37 p.m.
On Thu, 30 Jun 2011 12:57:44 +0100, Bryn M. Reeves wrote:
On 06/30/2011 01:31 AM, Patrick O'Callaghan wrote:
[....]
> It's a secret :-) Seriously, I noticed it maybe a year or so
ago and
> have mentioned it several times on this and other lists, but it's still
> not well-known. It certainly didn't exist 13 years ago. The earliest
> reference I can see in a quick Google is early 2010 (F12).
$ rpm -q --changelog yum-utils | grep -C1 needs-restarting * Wed Nov
04
2009 Seth Vidal <skvidal at fedoraproject.org> - add needs-restarting
I noticed it had appeared in yum-utils some time in the last year or so
- yum-utils is one of those packages that I infrequently do a rpm -ql
yum-utils | grep bin for in case anything new has popped up - I think
it's also been mentioned on the list a few times.
Oh good: if it's in yum-utils I have it on all machines. So does
it run itself, like at least some of the other things in that package? Or
should I be invoking it on occasion?
--
Beartooth Staffwright, Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
6:57 a.m.
On 06/30/2011 01:31 AM, Patrick O'Callaghan wrote:
On Wed, 2011-06-29 at 22:46 +0000, BeartoothHOS wrote:
> On Tue, 28 Jun 2011 17:38:34 +0100, Bryn M. Reeves wrote:
> [....]
>> Then you should know to run needs-restarting when it has finished to
>> check for this yourself.
>
> Maybe the OP knows, but in thirteen years of running linux
> (almost all RedHat or clones) I've never heard of it. And googling found
> me nothing comprehensible. Can you point me to something?
It's a secret :-) Seriously, I noticed it maybe a year or so ago and
have mentioned it several times on this and other lists, but it's still
not well-known. It certainly didn't exist 13 years ago. The earliest
reference I can see in a quick Google is early 2010 (F12).
$ rpm -q --changelog yum-utils | grep -C1 needs-restarting
* Wed Nov 04 2009 Seth Vidal <skvidal at fedoraproject.org>
- add needs-restarting
I noticed it had appeared in yum-utils some time in the last year or so -
yum-utils is one of those packages that I infrequently do a rpm -ql yum-utils |
grep bin for in case anything new has popped up - I think it's also been
mentioned on the list a few times.
Regards,
Bryn.
9:54 p.m.
On 06/30/2011 10:51 AM, Genes MailLists wrote:
I'm using 3.0 kernel from rawhide - which had a new procps as
a
requirement - so its possible things have changed in /proc ... also this
is systemd's area - its possible some capabilities are needed now which
were not in the past ? Clearly the regular unix permissions bits are
fine ...
I haven't seen you bring this up on the fedora-test list. Maybe
somebody there has the scoop?
9:51 p.m.
On 06/29/2011 08:35 PM, Patrick O'Callaghan wrote:
>
> From this we see:
>
>
> $ ls -l /proc/1/smaps
> 0 -r--r--r--. 1 root root 0 Jun 28 13:25 /proc/1/smaps
>
> $ cat /proc/1/smaps
> cat: /proc/1/smaps: Permission denied
>
> So that is the source of the problem - tho it probably should not give up.
But the mode bits allow reading, and on my system "cat /proc/1/smaps"
succeeds (though it's empty). I don't think those files have extended
attributes so that wouldn't be it.
Curiouser and curiouser, as Alice said.
poc
I'm using 3.0 kernel from rawhide - which had a new procps as a
requirement - so its possible things have changed in /proc ... also this
is systemd's area - its possible some capabilities are needed now which
were not in the past ? Clearly the regular unix permissions bits are
fine ...
7:35 p.m.
On Wed, 2011-06-29 at 09:15 -0400, Genes MailLists wrote:
On 06/29/2011 06:01 AM, Bryn M. Reeves wrote:
> print "pid: %s" % pid # add this line
Great idea:
./needs-restarting
pid: 1
Traceback (most recent call last):
File "./needs-restarting", line 138, in <module>
sys.exit(main(sys.argv))
File "./needs-restarting", line 118, in main
for fn in get_open_files(pid):
File "./needs-restarting", line 85, in get_open_files
for line in maps.readlines():
IOError: [Errno 13] Permission denied
From this we see:
$ ls -l /proc/1/smaps
0 -r--r--r--. 1 root root 0 Jun 28 13:25 /proc/1/smaps
$ cat /proc/1/smaps
cat: /proc/1/smaps: Permission denied
So that is the source of the problem - tho it probably should not give up.
But the mode bits allow reading, and on my system "cat /proc/1/smaps"
succeeds (though it's empty). I don't think those files have extended
attributes so that wouldn't be it.
Curiouser and curiouser, as Alice said.
poc
7:31 p.m.
On Wed, 2011-06-29 at 22:46 +0000, BeartoothHOS wrote:
On Tue, 28 Jun 2011 17:38:34 +0100, Bryn M. Reeves wrote:
[....]
> Then you should know to run needs-restarting when it has finished to
> check for this yourself.
Maybe the OP knows, but in thirteen years of running linux
(almost all RedHat or clones) I've never heard of it. And googling found
me nothing comprehensible. Can you point me to something?
It's a secret :-) Seriously, I noticed it maybe a year or so ago and
have mentioned it several times on this and other lists, but it's still
not well-known. It certainly didn't exist 13 years ago. The earliest
reference I can see in a quick Google is early 2010 (F12).
There was once a thread here (I know I was on it, and I think Alan Cox
too) which discussed how to detect when processes needed to be
restarted. Certainly no-one knew about n-r at that time and it wasn't so
very long ago. I even started hacking something together at the time.
Possibly that gave someone the idea to write n-r, but it's hard to tell.
poc
5:46 p.m.
On Tue, 28 Jun 2011 17:38:34 +0100, Bryn M. Reeves wrote:
[....]
Then you should know to run needs-restarting when it has finished to
check for this yourself.
Maybe the OP knows, but in thirteen years of running linux
(almost all RedHat or clones) I've never heard of it. And googling found
me nothing comprehensible. Can you point me to something?
--
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
10:23 a.m.
On 06/29/2011 08:18 PM, Patrick O'Callaghan wrote:
Hmm, I just did a similar experiment. yum updated systemd and a
couple
of other things. Under my normal user n-r reports no changes. Running as
root it reports:
# needs-restarting
1 :
/bin/systemd--log-levelinfo--log-targetsyslog-or-kmsg--system--dump-core--show-status=1--sysv-console=1--deserialize21
468 : /lib/systemd/systemd-logger
979 : /usr/sbin/modem-manager
1460 : -:0
This clearly requires further thought (or a BZ report).
This at least requires more thought....
In my case.... It would seem that root's report includes all processes
that would need a "restart" while the user's report is a subset of those
currently running under the UID.
Maybe we need to compare what packages were updated?
FWIW, I feel the output I'm seeing is "correct". So, I don't know that
I've anything to BZ.
8:15 a.m.
On 06/29/2011 06:01 AM, Bryn M. Reeves wrote:
print "pid: %s" % pid # add this line
Great idea:
./needs-restarting
pid: 1
Traceback (most recent call last):
File "./needs-restarting", line 138, in <module>
sys.exit(main(sys.argv))
File "./needs-restarting", line 118, in main
for fn in get_open_files(pid):
File "./needs-restarting", line 85, in get_open_files
for line in maps.readlines():
IOError: [Errno 13] Permission denied
From this we see:
$ ls -l /proc/1/smaps
0 -r--r--r--. 1 root root 0 Jun 28 13:25 /proc/1/smaps
$ cat /proc/1/smaps
cat: /proc/1/smaps: Permission denied
So that is the source of the problem - tho it probably should not give up.
gene
7:18 a.m.
On Wed, 2011-06-29 at 12:00 +0800, Ed Greshko wrote:
On 06/29/2011 11:42 AM, Ed Greshko wrote:
> On 06/29/2011 11:21 AM, Ed Greshko wrote:
>> But, it is interesting that it runs fast under the KDE's user and quick
>> on the ssh user. Neither of which is in the wheel group.
> I will have to remember this the next time packages are updated and I
> get an indication that a logout/login is needed. I'll run
> needs-restarting without the -u to test.... Hummm....as I type this I
> think I may have a VM that I can test it on.....
OK... FWIW.....
I logged in as a non-wheel user under KDE and ran "yum update" as root...
For the user I get the following.... (no -u)
2455 :
/usr/libexec/mysqld--defaults-file=/home/maria/.local/share/akonadi//mysql.conf--datadir=/home/maria/.local/share/akonadi/db_data/--socket=/home/maria/.local/share/akonadi/socket-f15.greshko.com/mysql.socket
2513 : /usr/bin/nepomukservicestubnepomukstorage
2518 :
/usr/bin/virtuoso-t+foreground+configfile/tmp/virtuoso_hX2513.ini+wait
2529 : /usr/bin/nepomukservicestubnepomukbackupsync
2574 : /usr/bin/pulseaudio--start--log-target=syslog
2577 : /usr/libexec/pulse/gconf-helper
2594 : python/usr/bin/printer-applet
2675 : /usr/libexec/gvfs-gphoto2-volume-monitor
2686 : /bin/bash
For root I get....
1 :
/bin/systemd--log-levelinfo--log-targetsyslog-or-kmsg--system--dump-core--show-status=0--sysv-console=0--deserialize30
2056 :
/usr/bin/Xorg:0-br-verbose-auth/var/run/gdm/auth-for-gdm-bkZQL8/database-nolistentcp
2455 :
/usr/libexec/mysqld--defaults-file=/home/maria/.local/share/akonadi//mysql.conf--datadir=/home/maria/.local/share/akonadi/db_data/--socket=/home/maria/.local/share/akonadi/socket-f15.greshko.com/mysql.socket
2513 : /usr/bin/nepomukservicestubnepomukstorage
2518 :
/usr/bin/virtuoso-t+foreground+configfile/tmp/virtuoso_hX2513.ini+wait
2529 : /usr/bin/nepomukservicestubnepomukbackupsync
2574 : /usr/bin/pulseaudio--start--log-target=syslog
2577 : /usr/libexec/pulse/gconf-helper
2594 : python/usr/bin/printer-applet
2675 : /usr/libexec/gvfs-gphoto2-volume-monitor
2686 : /bin/bash
2752 :
/sbin/dhclient-d-4-sf/usr/libexec/nm-dhcp-client.action-pf/var/run/dhclient-p2p1.pid-lf/var/lib/dhclient/dhclient-b92aa237-1b70-4a2b-9bbb-da15a3f0e599-p2p1.lease-cf/var/run/nm-dhclient-p2p1.confp2p1
2806 : sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
2808 : sendmail: accepting connections
2818 : su-
2826 : -bash
Hmm, I just did a similar experiment. yum updated systemd and a couple
of other things. Under my normal user n-r reports no changes. Running as
root it reports:
# needs-restarting
1 :
/bin/systemd--log-levelinfo--log-targetsyslog-or-kmsg--system--dump-core--show-status=1--sysv-console=1--deserialize21
468 : /lib/systemd/systemd-logger
979 : /usr/sbin/modem-manager
1460 : -:0
This clearly requires further thought (or a BZ report).
poc
3:52 a.m.
On 06/29/2011 04:43 AM, James McKenzie wrote:
On 6/28/11 8:24 PM, Ed Greshko wrote:
> On 06/29/2011 11:18 AM, James McKenzie wrote:
>> I was referring to /proc/<pid whatever> when that user did not
'own' the
>> process. I'm under the impression that this is/was part of the security
>> 'features' of Fedora Linux. I don't have a RH box to look at and
verify.
> Right.... Understand now....
>
> But, as poc has indicated, many of those owned even by root are readable.
Interesting. I have issues with that as a security professional but
then again ps -ef is also available and 'shows all'.
ps -ef is just formatting the data that it reads from /proc. It can access no
more and no less than anything else.
Regards,
Bryn.
11:38 a.m.
On 06/28/2011 05:18 PM, Petrus de Calguarium wrote:
Bryn M. Reeves wrote:
> For a couple of releases now the graphical updater tools have supported
> the ability to warn the user when this is the case. If you were using
> these tools then you should have received such a warning.
I run yum from the command line, as I feel I have both more control and am able
to see more clearly what is happening and why something fails, if it does.
Then you should know to run needs-restarting when it has finished to check for
this yourself.
Regards,
Bryn.
12:39 a.m.
On 06/28/2011 10:51 PM, Genes MailLists wrote:
On 06/28/2011 10:13 PM, James McKenzie wrote:
> On 6/28/11 6:37 PM, Genes MailLists wrote:
>>
>> Works fine as root.
> Usually ordinary users are prohibited from accessing /proc/<whatever>
> from what I remember. That is why root works and joe-blow does not.
>
> James McKenzie
>
I'm totally fine with it - but seems to work for some - curiosity now.
Hah - this machine has rawhide kernel and procps - I suspect the latter
could be a relevant difference to stock F15?
11 p.m.
On 06/29/2011 11:42 AM, Ed Greshko wrote:
On 06/29/2011 11:21 AM, Ed Greshko wrote:
> But, it is interesting that it runs fast under the KDE's user and quick
> on the ssh user. Neither of which is in the wheel group.
I will have to remember this the next time packages are updated and I
get an indication that a logout/login is needed. I'll run
needs-restarting without the -u to test.... Hummm....as I type this I
think I may have a VM that I can test it on.....
OK... FWIW.....
I logged in as a non-wheel user under KDE and ran "yum update" as root...
For the user I get the following.... (no -u)
2455 :
/usr/libexec/mysqld--defaults-file=/home/maria/.local/share/akonadi//mysql.conf--datadir=/home/maria/.local/share/akonadi/db_data/--socket=/home/maria/.local/share/akonadi/socket-f15.greshko.com/mysql.socket
2513 : /usr/bin/nepomukservicestubnepomukstorage
2518 :
/usr/bin/virtuoso-t+foreground+configfile/tmp/virtuoso_hX2513.ini+wait
2529 : /usr/bin/nepomukservicestubnepomukbackupsync
2574 : /usr/bin/pulseaudio--start--log-target=syslog
2577 : /usr/libexec/pulse/gconf-helper
2594 : python/usr/bin/printer-applet
2675 : /usr/libexec/gvfs-gphoto2-volume-monitor
2686 : /bin/bash
For root I get....
1 :
/bin/systemd--log-levelinfo--log-targetsyslog-or-kmsg--system--dump-core--show-status=0--sysv-console=0--deserialize30
2056 :
/usr/bin/Xorg:0-br-verbose-auth/var/run/gdm/auth-for-gdm-bkZQL8/database-nolistentcp
2455 :
/usr/libexec/mysqld--defaults-file=/home/maria/.local/share/akonadi//mysql.conf--datadir=/home/maria/.local/share/akonadi/db_data/--socket=/home/maria/.local/share/akonadi/socket-f15.greshko.com/mysql.socket
2513 : /usr/bin/nepomukservicestubnepomukstorage
2518 :
/usr/bin/virtuoso-t+foreground+configfile/tmp/virtuoso_hX2513.ini+wait
2529 : /usr/bin/nepomukservicestubnepomukbackupsync
2574 : /usr/bin/pulseaudio--start--log-target=syslog
2577 : /usr/libexec/pulse/gconf-helper
2594 : python/usr/bin/printer-applet
2675 : /usr/libexec/gvfs-gphoto2-volume-monitor
2686 : /bin/bash
2752 :
/sbin/dhclient-d-4-sf/usr/libexec/nm-dhcp-client.action-pf/var/run/dhclient-p2p1.pid-lf/var/lib/dhclient/dhclient-b92aa237-1b70-4a2b-9bbb-da15a3f0e599-p2p1.lease-cf/var/run/nm-dhclient-p2p1.confp2p1
2806 : sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
2808 : sendmail: accepting connections
2818 : su-
2826 : -bash
10:24 p.m.
On 06/29/2011 11:18 AM, James McKenzie wrote:
I was referring to /proc/<pid whatever> when that user did not
'own' the
process. I'm under the impression that this is/was part of the security
'features' of Fedora Linux. I don't have a RH box to look at and verify.
Right.... Understand now....
But, as poc has indicated, many of those owned even by root are readable.
10:43 p.m.
On 6/28/11 8:24 PM, Ed Greshko wrote:
On 06/29/2011 11:18 AM, James McKenzie wrote:
> I was referring to /proc/<pid whatever> when that user did not 'own'
the
> process. I'm under the impression that this is/was part of the security
> 'features' of Fedora Linux. I don't have a RH box to look at and
verify.
Right.... Understand now....
But, as poc has indicated, many of those owned even by root are readable.
Interesting. I have issues with that as a security professional but
then again ps -ef is also available and 'shows all'.
James
10:42 p.m.
On 06/29/2011 11:21 AM, Ed Greshko wrote:
But, it is interesting that it runs fast under the KDE's user and
quick
on the ssh user. Neither of which is in the wheel group.
I will have to remember this the next time packages are updated and I
get an indication that a logout/login is needed. I'll run
needs-restarting without the -u to test.... Hummm....as I type this I
think I may have a VM that I can test it on.....
10:21 p.m.
On 06/29/2011 11:12 AM, Patrick O'Callaghan wrote:
Only if invoked with the '-u' option.
I said it was a "quick read"... :-)
But, it is interesting that it runs fast under the KDE's user and quick
on the ssh user. Neither of which is in the wheel group.
> I ran it as a user running KDE....and it took several seconds to
> complete....lots of PIDs for that user.
>
> I ran it as a user that had ssh'd in. Completed very fast....only a
> couple of PIDs.
>
> Of course an ordinary user can access many /proc/<whatever> ....
>
> cat /proc/cpuinfo being one of many....
Not relevant. Only /proc/[0-9]* are considered.
I should have clarified. My statement was in the context of
/proc/<whatever> and not in what the script is looking at. But, as you
say, even many of those are world readable.
10:18 p.m.
On 6/28/11 8:04 PM, Ed Greshko wrote:
On 06/29/2011 10:51 AM, Genes MailLists wrote:
> On 06/28/2011 10:13 PM, James McKenzie wrote:
>> On 6/28/11 6:37 PM, Genes MailLists wrote:
>>> Works fine as root.
>> Usually ordinary users are prohibited from accessing /proc/<whatever>
>> from what I remember. That is why root works and joe-blow does not.
>>
>> James McKenzie
>>
> I'm totally fine with it - but seems to work for some - curiosity now.
>
> I wonder if those for whom it works are in group wheel or something -
> perhaps as my firstboot failed when systemd got its knickers in a twist
> with the luks passwords and firstboot and i915 graphics somehow first
> boot was a black screen .. dont recall now if f15 or f16 puts first user
> in wheel group - and if that matters at all.
>
>
I took a quick read of the python script....
It would seem that if one is not running as root it will check the PIDs
of the user invoking the command to see if any of those processes need
to be restarted.
I ran it as a user running KDE....and it took several seconds to
complete....lots of PIDs for that user.
I ran it as a user that had ssh'd in. Completed very fast....only a
couple of PIDs.
Of course an ordinary user can access many /proc/<whatever> ....
cat /proc/cpuinfo being one of many....
I was referring to /proc/<pid
whatever> when that user did not 'own' the
process. I'm under the impression that this is/was part of the security
'features' of Fedora Linux. I don't have a RH box to look at and verify.
Of course, I have been known to be incorrect and if I am in this case,
something else is happening then.
James
10:12 p.m.
On Wed, 2011-06-29 at 11:04 +0800, Ed Greshko wrote:
On 06/29/2011 10:51 AM, Genes MailLists wrote:
> On 06/28/2011 10:13 PM, James McKenzie wrote:
>> On 6/28/11 6:37 PM, Genes MailLists wrote:
>
>>> Works fine as root.
>> Usually ordinary users are prohibited from accessing /proc/<whatever>
>> from what I remember. That is why root works and joe-blow does not.
>>
>> James McKenzie
>>
> I'm totally fine with it - but seems to work for some - curiosity now.
>
> I wonder if those for whom it works are in group wheel or something -
> perhaps as my firstboot failed when systemd got its knickers in a twist
> with the luks passwords and firstboot and i915 graphics somehow first
> boot was a black screen .. dont recall now if f15 or f16 puts first user
> in wheel group - and if that matters at all.
>
>
I took a quick read of the python script....
It would seem that if one is not running as root it will check the PIDs
of the user invoking the command to see if any of those processes need
to be restarted.
Only if invoked with the '-u' option.
I ran it as a user running KDE....and it took several seconds to
complete....lots of PIDs for that user.
I ran it as a user that had ssh'd in. Completed very fast....only a
couple of PIDs.
Of course an ordinary user can access many /proc/<whatever> ....
cat /proc/cpuinfo being one of many....
Not relevant. Only /proc/[0-9]* are considered.
poc
10:04 p.m.
On 06/29/2011 10:51 AM, Genes MailLists wrote:
On 06/28/2011 10:13 PM, James McKenzie wrote:
> On 6/28/11 6:37 PM, Genes MailLists wrote:
>> Works fine as root.
> Usually ordinary users are prohibited from accessing /proc/<whatever>
> from what I remember. That is why root works and joe-blow does not.
>
> James McKenzie
>
I'm totally fine with it - but seems to work for some - curiosity now.
I wonder if those for whom it works are in group wheel or something -
perhaps as my firstboot failed when systemd got its knickers in a twist
with the luks passwords and firstboot and i915 graphics somehow first
boot was a black screen .. dont recall now if f15 or f16 puts first user
in wheel group - and if that matters at all.
I took a quick read of the python script....
It would seem that if one is not running as root it will check the PIDs
of the user invoking the command to see if any of those processes need
to be restarted.
I ran it as a user running KDE....and it took several seconds to
complete....lots of PIDs for that user.
I ran it as a user that had ssh'd in. Completed very fast....only a
couple of PIDs.
Of course an ordinary user can access many /proc/<whatever> ....
cat /proc/cpuinfo being one of many....
10 p.m.
On Tue, 2011-06-28 at 22:51 -0400, Genes MailLists wrote:
On 06/28/2011 10:13 PM, James McKenzie wrote:
> On 6/28/11 6:37 PM, Genes MailLists wrote:
>>
>> Works fine as root.
> Usually ordinary users are prohibited from accessing /proc/<whatever>
> from what I remember. That is why root works and joe-blow does not.
>
> James McKenzie
>
I'm totally fine with it - but seems to work for some - curiosity now.
I wonder if those for whom it works are in group wheel or something -
perhaps as my firstboot failed when systemd got its knickers in a twist
with the luks passwords and firstboot and i915 graphics somehow first
boot was a black screen .. dont recall now if f15 or f16 puts first user
in wheel group - and if that matters at all.
gene/
It doesn't (just tried it to check).
poc
9:58 p.m.
On Tue, 2011-06-28 at 19:13 -0700, James McKenzie wrote:
On 6/28/11 6:37 PM, Genes MailLists wrote:
> On 06/28/2011 08:17 PM, Daniel J Walsh wrote:
>>> Does this work as regular user for you? For me - selinux makes it
crash.
>> run ausearch -m avc -ts recent
>>
>> And see if it generates any output.
>>
>> SELinux error messages are written to /var/log/audit/audit.log
>>
>>
>>
> Thanks Dan - Nope no selinux logs on this one best I can tell. If I
> run as user I get:
>
> $ needs-restarting
> Traceback (most recent call last):
> File "/usr/bin/needs-restarting", line 137, in<module>
> sys.exit(main(sys.argv))
> File "/usr/bin/needs-restarting", line 117, in main
> for fn in get_open_files(pid):
> File "/usr/bin/needs-restarting", line 84, in get_open_files
> for line in maps.readlines():
> IOError: [Errno 13] Permission denied
>
>
> Its odd - line 117 in needs-restarting is this fragment:
>
>
> for pid in return_running_pids(uid=myuid):
> try:
> pid_start = os.stat('/proc/' + pid)[stat.ST_CTIME]
> except OSError, e:
> continue
> found_match = False
> for fn in get_open_files(pid):
>
> Works fine as root.
Usually ordinary users are prohibited from accessing /proc/<whatever>
from what I remember. That is why root works and joe-blow does not.
James McKenzie
In fact most of the contents of /proc/<pid> are world-readable. Try 'ls
-l /proc/<some-pid>'. Specifically, the smaps file is world-readable,
which is what needs-restarting uses to get the names of open files. It
essentially builds a table from the internal equivalent of "grep
fd: /proc/*/smaps".
I invariably run needs-restarting under my own user id just after
updating, and I have never seen the above traceback.
poc
9:51 p.m.
On 06/28/2011 10:13 PM, James McKenzie wrote:
On 6/28/11 6:37 PM, Genes MailLists wrote:
>
> Works fine as root.
Usually ordinary users are prohibited from accessing /proc/<whatever>
from what I remember. That is why root works and joe-blow does not.
James McKenzie
I'm totally fine with it - but seems to work for some - curiosity now.
I wonder if those for whom it works are in group wheel or something -
perhaps as my firstboot failed when systemd got its knickers in a twist
with the luks passwords and firstboot and i915 graphics somehow first
boot was a black screen .. dont recall now if f15 or f16 puts first user
in wheel group - and if that matters at all.
gene/
9:13 p.m.
On 6/28/11 6:37 PM, Genes MailLists wrote:
On 06/28/2011 08:17 PM, Daniel J Walsh wrote:
>> Does this work as regular user for you? For me - selinux makes it crash.
> run ausearch -m avc -ts recent
>
> And see if it generates any output.
>
> SELinux error messages are written to /var/log/audit/audit.log
>
>
>
Thanks Dan - Nope no selinux logs on this one best I can tell. If I
run as user I get:
$ needs-restarting
Traceback (most recent call last):
File "/usr/bin/needs-restarting", line 137, in<module>
sys.exit(main(sys.argv))
File "/usr/bin/needs-restarting", line 117, in main
for fn in get_open_files(pid):
File "/usr/bin/needs-restarting", line 84, in get_open_files
for line in maps.readlines():
IOError: [Errno 13] Permission denied
Its odd - line 117 in needs-restarting is this fragment:
for pid in return_running_pids(uid=myuid):
try:
pid_start = os.stat('/proc/' + pid)[stat.ST_CTIME]
except OSError, e:
continue
found_match = False
for fn in get_open_files(pid):
Works fine as root.
Usually ordinary users are prohibited from accessing
/proc/<whatever>
from what I remember. That is why root works and joe-blow does not.
James McKenzie
8:37 p.m.
On 06/28/2011 08:17 PM, Daniel J Walsh wrote:
> Does this work as regular user for you? For me - selinux makes
it crash.
run ausearch -m avc -ts recent
And see if it generates any output.
SELinux error messages are written to /var/log/audit/audit.log
Thanks Dan - Nope no selinux logs on this one best I can tell. If I
run as user I get:
$ needs-restarting
Traceback (most recent call last):
File "/usr/bin/needs-restarting", line 137, in <module>
sys.exit(main(sys.argv))
File "/usr/bin/needs-restarting", line 117, in main
for fn in get_open_files(pid):
File "/usr/bin/needs-restarting", line 84, in get_open_files
for line in maps.readlines():
IOError: [Errno 13] Permission denied
Its odd - line 117 in needs-restarting is this fragment:
for pid in return_running_pids(uid=myuid):
try:
pid_start = os.stat('/proc/' + pid)[stat.ST_CTIME]
except OSError, e:
continue
found_match = False
for fn in get_open_files(pid):
Works fine as root.
7:17 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2011 01:49 PM, Genes MailLists wrote:
On 06/28/2011 12:22 PM, Patrick O'Callaghan wrote:
>
> After updating, I always run needs-restarting to see what running
> processes are affected. I'm surprised more people don't seem to know
> about this program.
>
Does this work as regular user for you? For me - selinux makes it crash.
run
ausearch -m avc -ts recent
And see if it generates any output.
SELinux error messages are written to /var/log/audit/audit.log
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4KbzUACgkQrlYvE4MpobPF/wCg4fT4OQ49n3TvIA0AQ9K4gOxV
H8wAoJNzZq1VNqKfJIDCyPkv7ilcT2MX
=iXty
-----END PGP SIGNATURE-----
4:38 p.m.
On Tue, 2011-06-28 at 12:29 -0700, Joe Zeff wrote:
On 06/28/2011 09:41 AM, Patrick O'Callaghan wrote:
> If I had to pick out a single feature to demonstrate the superiority of
> the Unix style of system, this would be it.
De gustabus and all that jazz. I prefer to explain that Linux file
systems never (well, almost never) need defragging because that's
something J. Random User can understand.
Sure, but that's an implementation detail. The file reference idea is a
basic part of the system's "principles of operation" (and the reason for
the existence of inodes) which at some point the user would do well to
be aware of. Call it an aesthetic thing.
poc
2:16 p.m.
On Tue, 2011-06-28 at 12:01 -0700, Joe Zeff wrote:
On 06/28/2011 09:22 AM, Patrick O'Callaghan wrote:
> After updating, I always run needs-restarting to see what running
> processes are affected. I'm surprised more people don't seem to know
> about this program.
I do daily updates via yumex. Long ago I learned that the included
Update Manager was very good at finding updates but would always insist
that I wasn't on-line when it came to doing the update. I'd never heard
of needs-restarting before, so Thanx! BTW, having run it today, I
gather that no output means that you're OK?
Of course. In Unix or Linux the old adage applies: no news is good news.
poc
2:29 p.m.
On 06/28/2011 09:41 AM, Patrick O'Callaghan wrote:
If I had to pick out a single feature to demonstrate the superiority
of
the Unix style of system, this would be it.
De gustabus and all that jazz. I prefer to explain that Linux file
systems never (well, almost never) need defragging because that's
something J. Random User can understand.
1:57 p.m.
On 06/28/2011 09:21 AM, Petrus de Calguarium wrote:
Andrew Haley wrote:
> How could it be otherwise?
If a file has been deleted, the proper thing would be for the running process
to read the new copy into memory.
And how, pray tell, would the running process know that? In Unix and
Linux a file doesn't completely go away until the last program using it
closes the (otherwise deleted) file. Programs trying to open the file
will either get the new version, if there is one, or create a new copy
if it wasn't replaced. AFAIK, this has always been true, and what the
OP was complaining about is just the way things are. I can well
understand why the OP is Not Happy with the situation, but there's not
much that can be done about it.
2:07 p.m.
On 06/28/2011 02:46 PM, mike cloaked wrote:>
So no selinux problems for me - this is in f14 32 bit.
Or does it cause problems if there is a process that needs restarting?
Its 64 bit - and sealert is broken as well because of the libreport
"thing" ... I have run fixfiles restore ...
2:01 p.m.
On 06/28/2011 09:22 AM, Patrick O'Callaghan wrote:
After updating, I always run needs-restarting to see what running
processes are affected. I'm surprised more people don't seem to know
about this program.
I do daily updates via yumex. Long ago I learned that the included
Update Manager was very good at finding updates but would always insist
that I wasn't on-line when it came to doing the update. I'd never heard
of needs-restarting before, so Thanx! BTW, having run it today, I
gather that no output means that you're OK?
1:46 p.m.
On Tue, Jun 28, 2011 at 6:49 PM, Genes MailLists <lists(a)sapience.com> wrote:
> After updating, I always run needs-restarting to see what running
> processes are affected. I'm surprised more people don't seem to know
> about this program.
>
Does this work as regular user for you? For me - selinux makes it crash.
Right now nothing needs restarting as normal user for me - however running
$ needs-restarting -u
$ needs-restarting
$ needs-restarting -h
$ Usage:
needs-restarting: Report a list of process ids of programs that started
running before they or some component they use were updated.
Options:
-h, --help show this help message and exit
-u, --useronly show processes for my userid only
$
So no selinux problems for me - this is in f14 32 bit.
Or does it cause problems if there is a process that needs restarting?
--
mike c
1:46 p.m.
New subject: intel 5100 wifi card problem
Please don't hijack threads. Your topic has nothing to do with the
thread you posted in, because you used Reply instead of composing a new
message. See the list Guidelines at
http://fedoraproject.org/wiki/Mailing_list_guidelines
poc
1:44 p.m.
On Tue, 2011-06-28 at 13:49 -0400, Genes MailLists wrote:
On 06/28/2011 12:22 PM, Patrick O'Callaghan wrote:
>
> After updating, I always run needs-restarting to see what running
> processes are affected. I'm surprised more people don't seem to know
> about this program.
>
Does this work as regular user for you? For me - selinux makes it crash.
I haven't had any trouble with it, and I have SElinux enabled and
enforcing.
poc
1:04 p.m.
New subject: intel 5100 wifi card problem
Hi All!
I have a big and old problem with my toshiba satellite notebook's wifi.
The original wifi card was a realtek, which is always freezed, so after
a few months I decided to replace that card to an intel one. I searched
the net for full supported wifi card, and I found that intel wifi link
5100 will be the good choice for linux.
I get the interface, installed to my computer, and everything was fine
for a little time.
Now my problem is the card after few minutues or an hour hangs on. I
tried to associate the card again to my AP, but no success. I look after
for my dmesg, and here below my results:
[ 120.302525] iwlagn 0000:06:00.0: Aggregation not enabled for tid 0
because load = 0
[ 123.115878] process `skype' is using obsolete setsockopt SO_BSDCOMPAT
[ 123.542529] iwlagn 0000:06:00.0: iwlagn_tx_agg_start on ra =
74:ea:3a:a5:d3:28 tid = 0
[ 183.974273] SELinux: initialized (dev proc, type proc), uses
genfs_contexts
[ 400.474353] TCP lp registered
[ 1723.179600] iwlagn 0000:06:00.0: Error sending REPLY_ADD_STA: time
out after 500ms.
[ 1723.179611] HW problem - can not stop rx aggregation for tid 0
[ 1723.679449] iwlagn 0000:06:00.0: Error sending REPLY_ADD_STA: time
out after 500ms.
[ 1723.679458] HW problem - can not stop rx aggregation for tid 6
[ 1724.179220] iwlagn 0000:06:00.0: Error sending REPLY_QOS_PARAM: time
out after 500ms.
[ 1724.179230] iwlagn 0000:06:00.0: Failed to update QoS
[ 1724.678972] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1724.678984] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1725.178850] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1725.178860] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1725.678547] iwlagn 0000:06:00.0: Error sending REPLY_QOS_PARAM: time
out after 500ms.
[ 1725.678561] iwlagn 0000:06:00.0: Failed to update QoS
[ 1726.178336] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1726.178348] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1726.178369] iwlagn 0000:06:00.0: Stopping AGG while state not ON or
starting
[ 1726.680114] iwlagn 0000:06:00.0: Error sending REPLY_ADD_STA: time
out after 500ms.
[ 1726.680137] ieee80211 phy0: failed to remove key (0,
74:ea:3a:a5:d3:28) from hardware (-110)
[ 1727.179980] iwlagn 0000:06:00.0: Error sending REPLY_REMOVE_STA: time
out after 500ms.
[ 1727.179988] iwlagn 0000:06:00.0: Error removing station
74:ea:3a:a5:d3:28
[ 1727.679730] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1727.679740] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1729.680851] iwlagn 0000:06:00.0: fail to flush all tx fifo queues
[ 1730.180672] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1730.180687] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1730.686517] iwlagn 0000:06:00.0: Error sending REPLY_ADD_STA: time
out after 500ms.
[ 1730.686533] ieee80211 phy0: failed to remove key (1,
ff:ff:ff:ff:ff:ff) from hardware (-110)
[ 1730.686660] cfg80211: Calling CRDA to update world regulatory domain
[ 1731.187203] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1731.187211] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1731.627020] iwlagn 0000:06:00.0: Queue 4 stuck for 10000 ms.
[ 1731.627032] iwlagn 0000:06:00.0: On demand firmware reload
[ 1731.687024] iwlagn 0000:06:00.0: Error sending REPLY_RXON: time out
after 500ms.
[ 1731.687037] iwlagn 0000:06:00.0: Error clearing ASSOC_MSK on BSS (-110)
[ 1731.687059] iwlagn 0000:06:00.0: Request scan called when driver not
ready.
[ 1731.687325] cfg80211: World regulatory domain updated:
[ 1731.687331] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 1731.687337] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 1731.687343] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 1731.687348] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 1731.687354] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 1731.687359] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 1731.687707] cfg80211: Calling CRDA for country: HU
[ 1731.706420] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.720236] cfg80211: Regulatory domain changed to country: HU
[ 1731.720240] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 1731.720243] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 1731.720246] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 1731.720248] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 1731.720251] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz),
(N/A, 2700 mBm)
[ 1731.725271] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.744111] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.762903] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.781597] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.800298] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.818996] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
[ 1731.837699] iwlagn 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL
= 0xFFFFFFFF
.
.
.
.
And many MAC is in deep sleep message.
Is there any workaround or fix for my card?
Additional info, my card is placed my notebook sorrounded by pastic
parts, and there is no possibility to cool down the interface. Maybe
it's overheated.
Any suggestion? How I will able to use this card normally?
Thanks: Balazs
12:26 p.m.
New subject: gnu linux update question [solved]
Bryn M. Reeves wrote:
Then you should know to run needs-restarting when it has finished to
check
for this yourself.
Thanks for the info. Finally, after so many years, I *do* understand how it is
meant that it is not required to reboot.
12:23 p.m.
Patrick O'Callaghan wrote:
The upshot is that if a process has a file open, and that file is
replaced by a different one (using unlink and creat) then the process
will continue to use the old file and all its attributes. When the
process closes the file, or terminates, the reference disappears and the
system then recovers the space.
I make use of this when I save youtube movies. Flash deletes the file as soon
as it is downloaded, but as long as the flash/nspluginwrapper processes are
still running, the deleted file can be captured and copied to another location.
11:18 a.m.
Bryn M. Reeves wrote:
For a couple of releases now the graphical updater tools have
supported
the ability to warn the user when this is the case. If you were using
these tools then you should have received such a warning.
I run yum from the command line, as I feel I have both more control and am able
to see more clearly what is happening and why something fails, if it does.
11:41 a.m.
On Tue, 2011-06-28 at 10:21 -0600, Petrus de Calguarium wrote:
Andrew Haley wrote:
> How could it be otherwise?
If a file has been deleted, the proper thing would be for the running process
to read the new copy into memory.
And how is the process supposed to know? As for as it's concerned, the
file still exists. In fact it *does* still exist. It's a fundamental
feature of all Unix systems that a file only disappears when all
references to it go away. This includes both directory entries ("links")
and in-process open file descriptors.
To reinforce this principle, there is no "delete file" operation in Unix
(and Linux). There is only "unlink". Actually recovering space from the
file is a mere administrative detail that the system handles when
there's no longer any way to access the file contents.
The upshot is that if a process has a file open, and that file is
replaced by a different one (using unlink and creat) then the process
will continue to use the old file and all its attributes. When the
process closes the file, or terminates, the reference disappears and the
system then recovers the space. Meanwhile, a new directory entry with
the same name is pointing at the new contents.
On other systems you often see messages such as "Windows cannot update
until the following processes have exited". That's because Windows uses
the (broken) DOS model which doesn't distinguish between the file and
references to it.
If I had to pick out a single feature to demonstrate the superiority of
the Unix style of system, this would be it.
poc
11:34 a.m.
On 06/28/2011 05:21 PM, Petrus de Calguarium wrote:
Andrew Haley wrote:
> How could it be otherwise?
If a file has been deleted, the proper thing would be for the running process
to read the new copy into memory.
That's not always possible. It's certainly not possible if one of
the changed files is an executable or a shared library.
Andrew.
11:22 a.m.
On Tue, 2011-06-28 at 17:14 +0100, Bryn M. Reeves wrote:
On 06/28/2011 05:07 PM, Andrew Haley wrote:
> On 06/28/2011 04:59 PM, Petrus de Calguarium wrote:
>> It is common knowledge that one does not need to reboot for updates to take
>> effect in GNU Linux.
>>
>> However, in actual practice, this is not so. I could cite many examples, but
>> this should suffice:
>>
>> On Sunday evening, I installed a new updates-testing version of mesa and then I
>> suspended the machine for the night. The following Monday morning (yesterday),
>> I resumed the machine and suspended it again around noon. I again resumed the
>> machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An
>> hour or two after that, I powered it back up and the mesa testing update turned
>> out to be bad and I was not able to log in. I did not know which program was at
>> fault, because the bad program had been installed over 24 hours prior, but was
>> only showing itself to be bad after a power off.
>>
>> Could someone explain how reboots are not needed in Linux for updates to
>> _take_, given the evidence to the contrary.
>
> If a process has a file open and that file is replaced with a new copy,
> the process is still using the file handle for the old file. This is
> normal UNIX, nothing new. How could it be otherwise?
Or to put it in simpler terms: when you update a component you need to re-start
the application(s) that use that component. When that is a component of the
whole desktop environment (like mesa) you will need to log out of your session
and log back in again.
For a couple of releases now the graphical updater tools have supported the
ability to warn the user when this is the case. If you were using these tools
then you should have received such a warning.
Note that suspending and resuming does not count here since you are simply
suspending the running (old) copy and then resuming it with open files and other
state intact.
After updating, I always run needs-restarting to see what running
processes are affected. I'm surprised more people don't seem to know
about this program.
BTW it's a Python script of only a couple of pages in length. Figuring
out how it works is a good exercise in understanding Linux (not to
mention Python :-)
poc
11:14 a.m.
On 06/28/2011 05:07 PM, Andrew Haley wrote:
On 06/28/2011 04:59 PM, Petrus de Calguarium wrote:
> It is common knowledge that one does not need to reboot for updates to take
> effect in GNU Linux.
>
> However, in actual practice, this is not so. I could cite many examples, but
> this should suffice:
>
> On Sunday evening, I installed a new updates-testing version of mesa and then I
> suspended the machine for the night. The following Monday morning (yesterday),
> I resumed the machine and suspended it again around noon. I again resumed the
> machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An
> hour or two after that, I powered it back up and the mesa testing update turned
> out to be bad and I was not able to log in. I did not know which program was at
> fault, because the bad program had been installed over 24 hours prior, but was
> only showing itself to be bad after a power off.
>
> Could someone explain how reboots are not needed in Linux for updates to
> _take_, given the evidence to the contrary.
If a process has a file open and that file is replaced with a new copy,
the process is still using the file handle for the old file. This is
normal UNIX, nothing new. How could it be otherwise?
Or to put it in simpler terms: when you update a component you need to re-start
the application(s) that use that component. When that is a component of the
whole desktop environment (like mesa) you will need to log out of your session
and log back in again.
For a couple of releases now the graphical updater tools have supported the
ability to warn the user when this is the case. If you were using these tools
then you should have received such a warning.
Note that suspending and resuming does not count here since you are simply
suspending the running (old) copy and then resuming it with open files and other
state intact.
Regards,
Bryn.
11:07 a.m.
On 06/28/2011 04:59 PM, Petrus de Calguarium wrote:
It is common knowledge that one does not need to reboot for updates
to take
effect in GNU Linux.
However, in actual practice, this is not so. I could cite many examples, but
this should suffice:
On Sunday evening, I installed a new updates-testing version of mesa and then I
suspended the machine for the night. The following Monday morning (yesterday),
I resumed the machine and suspended it again around noon. I again resumed the
machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An
hour or two after that, I powered it back up and the mesa testing update turned
out to be bad and I was not able to log in. I did not know which program was at
fault, because the bad program had been installed over 24 hours prior, but was
only showing itself to be bad after a power off.
Could someone explain how reboots are not needed in Linux for updates to
_take_, given the evidence to the contrary.
If a process has a file open and that file is replaced with a new copy,
the process is still using the file handle for the old file. This is
normal UNIX, nothing new. How could it be otherwise?
Andrew.
5:01 a.m.
On 06/29/2011 06:39 AM, Genes MailLists wrote:
On 06/28/2011 10:51 PM, Genes MailLists wrote:
> On 06/28/2011 10:13 PM, James McKenzie wrote:
>> On 6/28/11 6:37 PM, Genes MailLists wrote:
>
>
>>>
>>> Works fine as root.
>> Usually ordinary users are prohibited from accessing /proc/<whatever>
>> from what I remember. That is why root works and joe-blow does not.
>>
>> James McKenzie
>>
>
> I'm totally fine with it - but seems to work for some - curiosity now.
>
Hah - this machine has rawhide kernel and procps - I suspect the latter
could be a relevant difference to stock F15?
Not really. The procps package is just the userspace ps tools that use the /proc
file system as the data source (the name is a bit of a throwback).
There was some bugs waaay back in RHEL4/5 where the maps/smaps files were
created with overly restrictive permisions (S_IRUSR - read only for the owner of
the file) which caused problems for SUID applications that dropped their root
privileges but there's been nothing like this in Fedora's kernels for years
(that I know of anyway):
https://bugzilla.redhat.com/show_bug.cgi?id=322881 [RHEL5]
Did you determine what PID the script is accessing when you hit the backtrace?
A quick and dirty way to determine this is to copy the script to /tmp and add a
line to the top of the get_open_files() function like this (patch below):
def get_open_files(pid):
print "pid: %s" % pid # add this line
Then make the script in /tmp executable (chmod +x) and run it. It will spew out
lots of pids, the last one before the backtrace is the one you are interested in.
Regards,
Bryn.
--- /usr/bin/needs-restarting 2011-02-08 10:17:42.000000000 +0000
+++ /tmp/needs-restarting 2011-06-29 09:57:32.125200206 +0100
@@ -73,6 +73,7 @@ def return_running_pids(uid=None):
return pids
def get_open_files(pid):
+ print "pid: %s" % pid
files = []
smaps = '/proc/%s/smaps' % pid
try:
1:46 p.m.
On 06/28/2011 08:59 AM, Petrus de Calguarium wrote:
Could someone explain how reboots are not needed in Linux for updates
to
_take_, given the evidence to the contrary.
If I'm not mistaken (and I could be) mesa is part of the graphics
subsystem. If so, simply suspending your computer and coming back would
not unload the old version and load the new. Logging out and back in,
however, would.
12:12 p.m.
On Tue, Jun 28, 2011 at 11:52:17AM -0430, Patrick O'Callaghan wrote:
On Tue, 2011-06-28 at 17:14 +0100, Bryn M. Reeves wrote:
> On 06/28/2011 05:07 PM, Andrew Haley wrote:
> > On 06/28/2011 04:59 PM, Petrus de Calguarium wrote:
> >> It is common knowledge that one does not need to reboot for updates to take
> >> effect in GNU Linux.
> >>
> >> However, in actual practice, this is not so. I could cite many examples,
but
> >> this should suffice:
> >>
> >> On Sunday evening, I installed a new updates-testing version of mesa and
then I
> >> suspended the machine for the night. The following Monday morning
(yesterday),
> >> I resumed the machine and suspended it again around noon. I again resumed
the
> >> machine at about suppertime and _powered_ _it_ _down_ about 2 hours later.
An
> >> hour or two after that, I powered it back up and the mesa testing update
turned
> >> out to be bad and I was not able to log in. I did not know which program
was at
> >> fault, because the bad program had been installed over 24 hours prior, but
was
> >> only showing itself to be bad after a power off.
> >>
> >> Could someone explain how reboots are not needed in Linux for updates to
> >> _take_, given the evidence to the contrary.
> >
> > If a process has a file open and that file is replaced with a new copy,
> > the process is still using the file handle for the old file. This is
> > normal UNIX, nothing new. How could it be otherwise?
>
> Or to put it in simpler terms: when you update a component you need to re-start
> the application(s) that use that component. When that is a component of the
> whole desktop environment (like mesa) you will need to log out of your session
> and log back in again.
>
> For a couple of releases now the graphical updater tools have supported the
> ability to warn the user when this is the case. If you were using these tools
> then you should have received such a warning.
>
> Note that suspending and resuming does not count here since you are simply
> suspending the running (old) copy and then resuming it with open files and other
> state intact.
After updating, I always run needs-restarting to see what running
processes are affected. I'm surprised more people don't seem to know
about this program.
wow! I never heard of that one before. I'll certainly be checking it out.
thanks, Patrick!
BTW it's a Python script of only a couple of pages in length. Figuring
out how it works is a good exercise in understanding Linux (not to
mention Python :-)
poc
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
I can do all things through Christ
who strengthens me.
------------------------------ Philippians 4:13 -------------------------------
4689
days inactive
4696
days old
54 comments
13 participants
participants (13)
-
Andrew Haley -
Beartooth -
Bryn M. Reeves -
Daniel J Walsh -
Ed Greshko -
Fred Smith -
Genes MailLists -
Hüvely Balázs -
James McKenzie -
Joe Zeff -
mike cloaked -
Patrick O'Callaghan -
Peter G.