Bugzilla Bug 95173

Wondering why my scripts in /etc/apm/event.d are no longer being run during
suspend/resume, I found that run-parts no longer works on my x86.  As detailed
@
http://forums.gentoo.org/viewtopic-t-316582-highlight-debianutils.html?sid=e6e6780f08d28a60f1bd8208fc6e2e89
I added =sys-apps/debianutils-2.13.1-r1 to my /etc/portage/package.mask file
and re-emerged debianutils, effectively downgrading debianutils to the next
version. Version 1.16.4 works fine.  

Unfortunately, the failing run-parts does not give any error information. It
stays completely silent when run with the --test or --list flags and is unable
to locate any scripts in the directory given on the commandline.

seems it hates it when you have a file with a '.' in the name

> seems it hates it when you have a file with a '.' in the name

It sure does. I was just about to file a bug on it to open up the matter for
discussion then I saw this. The problem is this, when run-parts is run *without*
the --lsbsysinit parameter then it will accept scripts that "consist entirely of
upper and lower case letters, digits, underscores, and hyphens." However, if
this parameter is supplied then it will accept scripts that fall into the
following namespaces (regexes shown):

LANANA-assigned namespace: (^[a-z0-9]+$)
LSB heirarchical and reserved: (^_?([a-z0-9_.]+-)+[a-z0-9]+$)
Debian namespace: (^[a-z0-9][a-z0-9-]*$)

Frankly, the "LSB-compliant" behaviour makes a hell of a lot more sense to me.
It seems common for various packages in various distros to append the ".cron"
suffix to some cron scripts and Gentoo is no exception. I know of one situation
where this causes breakage: app-admin/logrotate provides a
"/etc/cron.daily/logrotate.cron" script. The sys-process/anacron package makes
use of run-parts and the stock /etc/ancrontab calls run-parts without the
parameter, the result being that logrotate is never run by anacron (well, I had
a great deal of fun (?) trying to track that one down for one user who was
complaining of this problem ;) vixie-cron is not affected by the issue.

I don't know which other packages use run-parts, if any, but this is a problem
IMO. The point is that this isn't Debian and we cannot categorically state that
cron scripts provided by packages (or even commonly provided by users) will fall
into the rather strict "Debian" namespace. I, for one, rather like the
convention of appending the ".cron" suffix. I _really_ think that there should
be a way for the LSB-compliant behaviour to be stipulated as a default.

In fact, some guy already raised the matter as a Debian bug (albeit not in much
depth):

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308911

The number of pending bugs on that package in their BTS does not make me feel
confident that any real discussion concerning the matter is going to arise soon!

I'm going to file a separate bug on anacron and propose a default config file
that would invoke run-parts with the --lsbsysinit parameter and reference this
bug as background material. Also, I researched the way in which Red Hat do this
and they don't use debian-utils at all. I'm attaching their run-parts script
here *purely* for informational purposes (from their cron-tabs packages and
equivalent in both Fedora and RHEL). I'm not suggesting that we should adopt the
same approach; Debian's seems more complete and better thought out.

Created an attachment (id=61660) [edit]
run-parts (script from RHEL4/FC4)

Attached for informational purposes.

Bug 96730 indicates that this change in behavior is on purpose ...

try running with the '--lsbsysinit' option

oops, didnt see your previous comment ;)

Sorry guys, the information I gave here was somewhat erroneous (got a heads up
at http://forums.gentoo.org/viewtopic-p-2563516.html). I based my conclusion
that the "LSB heirarchical/reserved" namespace resolved the issue upon my
experiences trying to help someone who was having difficulty with the
"logrotate.cron" script. Unfortunately, it transpires that the script itself had
been renamed and was thus compliant with the Debian namespace anyway. But I had
thought that throwing in --lsbsysinit had done the trick :(

So I'm re-opening this basically for two reasons:

1) To explain (correctly this time I hope) what the situation is.
2) To enquire what the best thing is to be done about it.

OK, so I should really learn to pay closer attention to others' regular
expressions ... the purpose of "(^_?([a-z0-9_.]+-)+[a-z0-9]+$)" is to enforce
the LSB/heirarchical namespace and is the _only_ one that allows a fullstop to
be used in any way. But in a particular way. For example "gentoo.org-foo" would
be valid whereas "gentoo.org-foo.sh" and "gentoo.org-foo.cron" would not be
valid. The official LSB blurb can be found here:

http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/scrptnames.html

The implication seems pretty clear; the upshot is that suffixes of the kind that
we've been used to are out. Script names are supposed to be registered via
LANANA wherever possible (if in common use) otherwise the heirarchical namespace
is encouraged such as "gentoo.org-foo" (which presumably reflects the
orientation to the specific distro).

So what should be done about it? I daresay that not many packages in portage are
affected by this (I only know specifically of logrotate though there may be some
others). So they could just have their "suffixes" chopped off perhaps (almost
sounds painful). But there is also the broader implication of whether we might
be able to do a better job of following this LSB stuff? Or is it a crock of dung
and not worth the bother? So what to do next ... opinions?

Here's the "official" LANANA list too if anyone's interested:
http://www.lanana.org/lsbreg/init/init.txt

Perhaps it would be a good idea to add some ewarn noise about this. Attaching
an
example patch against debianutils-2.14.1.ebuild.

Created an attachment (id=63110) [edit]
debianutils-2.14.1-namespace-warning.patch

Warn the user about changes introduced >=debianutils-2.2.

other than adding a warning to debian-utils as you proposed, i dont really see
what else should be done

Well for example, there is no mention of this topic in the Developer Handbook
(which doesn't really discuss anything other than ebuild design). The unofficial
"Gentoo Developer Guide" at http://dev.gentoo.org/~plasmaroo/devmanual/ simply
points to a section in the handbook:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4.
And that doesn't discuss any form of name standardisation whatsoever.

I realise that this might seem like small potatoes in the great scheme of things
but consider that this change in debianutils has already demonstrably caused
user confusion (at least in the forums, here in bugzilla, and in the form of the
conversation I had with the fellow anacron user on IRC). Take a look at this:

$ cd /usr/portage && find -iname "*.cron"
./mail-filter/dspam/files/dspam.cron
./app-portage/esearch/files/eupdatedb.cron
./net-mail/qmail-notify/files/qmail-notify.cron
./app-antivirus/vlnx/files/uvscan.cron
./app-admin/tmpwatch/files/tmpwatch.cron
./app-admin/logrotate/files/logrotate.cron
./app-admin/tripwire/files/tripwire.cron
./sys-apps/man/files/makewhatis.cron
./media-tv/mythtv/files/mythfilldatabase.cron
./app-text/man2html/files/man2html.cron
./net-analyzer/vnstat/files/vnstat.cron
./net-nntp/leafnode/files/texpire.cron
./net-nntp/leafnode/files/fetchnews.cron
./app-forensics/rkhunter/files/rkhunter.cron
./app-forensics/chkrootkit/files/chkrootkit.cron
./sys-libs/libtrash/files/cleanTrash.cron
./sys-fs/raidtools/files/raidtools.cron
./net-proxy/squid/files/squid-r1.cron

None of these will work with run-parts anymore and will, at least, completely
fail to be executed by anacron.

Also, The awareness of this issue seems generally low so what's to stop
something being committed in the future which falls foul of these changes? So to
clarify what I was getting at:

1) I was enquiring if perhaps a better job could be done of following LSB
recommendations when it comes to this topic in general. I'm not suggesting
anything in particular here (I'm just another Joe Nobody) but wanted to raise
the question and was interested in what you had to say.

2) If not, then I'm assuming it's a case of "we go on as usual, but take care to
stick rigorously to names that match (^[a-z0-9][a-z0-9-]*$)" (except for various
init.d scripts).

3) Either way, I think that perhaps just a paragraph or two on the topic would
not hurt. If it prevents even one mistake from being made in the future or
prevents just one more user hitting bugzilla/forums then wouldn't it be worthwhile?

4) Adding a warning to the ebuild seems prudent (although I'm not sure how many
people read their enotices closely).

5) All in all, I'd like to know how the problem with the *.cron scripts should
best be addressed because I'd like it fixed. May I start filing bugs against
each package affected suggesting that the ".cron" extension is dropped? Is there
a better way? Please throw me a bone :)

With regard to (3) I realise developers are busy people so I'd be willing to
bash out something on this and attach it here if interested.

Adding cron herd - hope that's OK.

imo imposing naming restrictions on files in /etc/cron.*/ is retarded

i use dcron personally and have never experienced these kind of issues ... what
cron packages use run-parts anyways ?

vixie-cron, and i dont know if the cron people added the stuff for /etc/cron.*
for dcron, etc as well ...

I say we just rip that bit out run-parts ...

create a new namespace (call it Gentoo-no-bs) and set it as the default ?

That I know of? anacron, as explored on bug 96730 (which unfortunately still
applies - yes, it was partly my fault that it was believed resolved but hey, I'm
not perfect). Some of us actually do use anacron. And having it not run a bunch
of cron scripts because of this new naming restriction is a bug - plain and
simple. Let me be frank: I expect things that use run-parts to work out of the
box and other users surely feel the same. So, as far as the anacron issue goes,
it really is quite simple:

1) Stop using run-parts in the anacrontab (use an alternative - such as the
example script from Red Hat or whatever <shrug>)
2) Rename the scripts themselves (at least, that's been ruled out now)
3) Modify run-parts to be more tolerant (hacking up debianutils)

What other alternatives could there possibly be? Perhaps I should have re-opened
the other bug first in which case I apologise. I am only trying to help. But I
can definitely state that at _least_ 18 different packages provide cron scripts
which will not be executed by anacron. As for whatever else uses run-parts I
really have not the faintest idea.

<quote="SpanKY">create a new namespace (call it Gentoo-no-bs) and set it as the
default ?</quote>

Attaching a patch that does exactly that ...

Created an attachment (id=63185) [edit]
Allow for periods in the "classical" namespace

Allows for periods in the "classical" namespace (that which is in effect when
the --lsbsysinit is *not* used). Also updates the manpage and adds some Gentoo
Technologies copyright blurb.

Bah, I meant to write "Gentoo Foundation", not "Gentoo Technologies". Adding
patch again. By the way, if this approach was used then the action taken in bug
96730 would need to be reversed. That would completely solve my beef apropos of
anacron.

Created an attachment (id=63186) [edit]
debianutils-2.14.1-no-bs-namespace.patch

Cite "Gentoo Foundation" in the manpage, not "Gentoo Technologies".

Created an attachment (id=63187) [edit]
debianutils-2.14.1-no-bs-namespace.patch (+veto filenames beginning with
period)

Similar to attachment 63186 [edit] but does not allow the filename to begin with a
period (this prevents it from attempting to execute hidden files including
".keep" whilst maintaining a high level of naming flexibility). Updated manpage
to reflect that.

Patch looks all right.  I removed the copyright stuff though, as that might be
more of an issue.  Fixed in -r1, thanks.

Thanks Martin. I've re-opened the anacron bug asking to revert the changes.
Should be OK to do that ahead of the debianutils bump being marked stable
because, as I already stated, the use of the "--lsbsysinit" parameter to attempt
to solve the problem was erroneous anyway.