On: Kill init by touching a bunch of files

[nodata]

Really? How?

[masklinn → nodata]

Because the bug kills pid1 which took down production boxes:

> I should point out that this is not theoretical. I went through all of the above because some real machines hit this for some reason. I don't have access to them, so I had to work backwards from just the message logged by init.

> […]

> Let me say this again: this happens in the wild. The "touch * * *..." repro looks contrived, because, well, that's the whole point of a repro.

[nodata → masklinn]

No, how did you accidentally write to /etc/init.d?

[masklinn → nodata]

> No, how did you accidentally write to /etc/init.d?

Let me quote again, with a finer slicing:

> I went through all of the above because some real machines hit this for some reason. I don't have access to them

[nodata → masklinn]

So you don't know? Gotcha.

[raverbashing → nodata]

And you apparently never managed anything in production.

Have you ever heard of "reproducing a problem"?

[nodata → raverbashing]

I've never seen anything write to /etc/init.d in production (or anywhere actually), which is why I asked for the root cause.

[gpvos → nodata]

Without, all the time, bothering to read the article, and asking here something that no-one here could know, because it's not in the article. If you really wanted to know, you could have mailed the author.

Boy, do you deserve these downvotes.

[cdelsolar → gpvos]

How do I get downvote access? I'm jelly.

[csours → cdelsolar]

Get a high enough score. Also don't use words like jelly. HN doesn't like reddit's tendency to use funny memes etc.

[gohrt → csours]

"jelly" is a word, not a funny meme. (Also, it's Hacker News, not Not-Reddit News.)

[cdelsolar → gohrt]

Thank you.

[raverbashing → nodata]

From the article Upstart is watching /etc so the example might have used /etc/init.d just to illustrate it

But yes, it is really strange. This usually means some weird proprietary tools

[Ded7xSEoPKYNsDd → raverbashing]

I'm a bit out of the loop on this stuff, but isn't this kind of thing (bulk-rewriting stuff in /etc) exactly what configuration management systems do in their normal operation?

[Sanddancer → Ded7xSEoPKYNsDd]

I don't have a chef/puppet/etc system handy at the moment, but could this possibly be the result of someone setting a file immutable, with the chef recipe dealing with that bit of the filesystem changing, causing chef to repeatedly trying to apply a changeset?

[kordless → nodata]

The author indicates the watcher also follows /etc, so any files written there could cause this as well.

[chris_wot → nodata]

That's the point.

[jandrese → nodata]

Maybe someone untarred a ton of config files into /etc and hit this limit?