what needs to be restarted

A common problem I’ve encountered for years is how to know what daemons need to be restarted in order to take advantage of some update or to be sure that they are running the secure version of the libs you just updated. I was thinking about this yesterday and realized I had all the tools necessary to find this out.

I came up with this simple script: needs_to_be_restarted.py

Now, it might be a bit overly simple and that is why I’m asking here. All it does is go through each of the processes in /proc/###### open the smaps file and look for files. For any of the files in there, it checks if a pkg owns them. If it does it checks what the installtime is on that package. If the installtime of the package is newer than when the process was started then it reports that pid (and the cmdline).

Now, this won’t work in every case, and I may have it report if the files have been removed but it seems to work pretty well.

If there are more foolproof ways to know or additional checks I should add, let me know.

If this looks good I’ll probably add some options and add it to yum-utils.

rail system

A semi-heartening comment today from this cnnfn article:

“Our country’s future prosperity depends on its having an efficient and well-maintained rail system,” Buffett said in a statement.

yum nag plugin

James and I were talking on irc about things we see in bugs that make us cringe. That people  are doing on their systems with yum or rpm or vaguely related. It reminded me of this list of  sysadmin aphorisms that I worked on about 3 or 4 yrs ago now.

So I was thinking what we need is a  yum nag plugin that when you run it as root it would emit some warnings about things you probably don’t want to be doing. Examples:

1. Warning: You have 10+ plugins installed and enabled, this is probably going to have odd effects

2. Warning: You have more than 5000 pkgs installed. Do you really need all that stuff?

3. Warning: Your system has been up for 528 days. Massive uptimes aren’t  as cool as you think

4. Warning: We’ve search ~/.bash_history and found evidence of –force and/or –nodeps – these are not wise.

5. Warning: You’ve disabled gpg checking. Bad, Bad.

6. Warning: You have 10 repositories enabled and 30 available. Seriously?

7. Warning: You have 4 versions of perl|python|ruby installed – this is just going to end in tears

8. Warning: Rawhide is enabled. I hope you know what you’re doing.

9. Warning: You have kernel modules installed. Good luck with those distro upgrades.

 

What else should be added here?

 

unicide

I’ve heard of freudian slips but I really didn’t mean to type unicide.

Tim caught the issue but I think I could start a whole set of descriptions of the times unicode in python has made me want to commit unicide.

 

Limits to Growth

I’ve talked about concerns about resource constraints and population control before on this blog but that’s been in the context of fuel and food resources for everyone on the whole planet. I’d like to talk about limits to growth with regard to fedora.

Today rawhide is showing 15,131 packages. The primary sqlite metadata is 41M uncompressed, 9.7MB compressed.

That’s a pretty serious number on both counts.

Each pkg is roughly 3K in primary, between primary and filelists the number comes out as about 8k per pkg.

Not a towering number but one we have to think about and keep in mind as we grow. Not only that number but also the disk space we use for cvs, lookaside cache, mirrors, koji, the processing time for building all those and the overhead of keeping track and riding herd over all the users/contributors who are maintaining all these pieces.

Now, we can add more infrastructure and have more layers to help deal with the growth but we’re way beyond a human-scale operation anymore. Any one person is not going to be able to keep track of everything going on by themselves. Even with tools the management level is too chaotic to create a structured view of it. To know where everything is.

So the question I have is this: at what point do we think about this and take action? Anyone who says ‘never’ gets a remedial lesson in entropy.

And the follow on question: If it were up to you, how would you do it?

someone banned from planet fedora? umm no.

I’ve been catching up on planet fedora a bit and I noticed the conversation about Tatica’s 365 project being banned from the planet? I have no idea who made that line of crap up but let me make it very clear:

The last edit made to the file which is used to ban/block folks from the planet was august 15th due to someone’s blog getting cracked and spammed, I believe.

Tatica’s posts have not been banned by planet fedora and there have been zero requests from anyone to do so.

In my ridiculously arrogant opinion her blog posts from her 365 project are welcome.

terminology

I was reading the fracas about things that were said at some conference and then various people’s replies about how to refer to groups so as not to offend others and I realized there is a bizarre parallel that my S.O. pointed out to  me years ago from the knitting community.

If you need to refer to the overwhelming group of people who are not computing-involved and/or not open-source/linux involved – then refer to them by their lack of knowledge of the arcane magic: they are muggles.

Muggles is gender neutral, it’s an accurate representation, I’d say, based on the usage from harry potter books and it is not obviously a pejorative (depending on how it is used, of course (then again I can make ‘beautiful’ into a pejorative if I say it properly)).

What do you think? Muggles? good word for the non-computing/non-linux majority?

“We want to make [fedora|linux] easy enough so it is possible for muggles to easily setup their printers.”

The knitting world seems to refer to non-knitters as muggles for the exact same reason – there is arcane magic that non-knitters do not know.

carl sagan

I saw this video at Stephen’s blog.

Colorpulse and carl sagan

Just fantastic to listen to.

translation discussion

James Antill and I talked about translation information the other day for a while. I decided to finally write up my impressions of what we talked about. I

Translations in packages/spec files:

translations (specspo) suck. A lot, in fact. You have to update a pkg constantly for information that is mostly  used in searching or listing pkg information.

There appear to be 2 times when you need to the translations:

1. searching for something you want: yum search blah
2. displaying info on something you have installed and don’t know what it does: yum info pkg or rpm -qi pkg

if we move all the description/summary translations into an additional metadata type in the repodata – and store them per lang/locale then only the lang the yum process is running as need be downloaded.

Once a package is installed the translated metadata would be stored in the yumdb so yum and yum-using tools can access it again. Alternatively if rpm has a place for us to stow this information in/around the rpmdb we can use that in lieu of the yumdb.

On the basis that most summary and description fields do not change often we could call for the translation freeze in package specs then the translators could do it all in transifex. We’d build the translation metadata from the repo that transifex writes to either at distro create and updates-push  times or really just whenever.

That’s the brunt of it.

ticket 182

Seriously,

if you’re working with yum and you encounter an error like:

Running rpm_check_debug ERROR with rpm_check_debug vs depsolve:

and it says anything about kernels and/or kernel-modules. Please see ticket 182 before filing a new ticket.

thanks.