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.
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.
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.
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.
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
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.
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.
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
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
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.
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.
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
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
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
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.
On Tue, Jun 28, 2011 at 6:49 PM, Genes MailLists lists@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?
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.
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?
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 ...
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
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.
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
-----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
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.
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
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/
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
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
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....
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
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
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.
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.
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.....
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
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
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?
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.
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:
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
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
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.
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?
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
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
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 ...
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?
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.
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?
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
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.
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.
-
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.