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 attachment 61660 [details] 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 attachment 63110 [details, diff] 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 attachment 63185 [details, diff] 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 attachment 63186 [details, diff] debianutils-2.14.1-no-bs-namespace.patch Cite "Gentoo Foundation" in the manpage, not "Gentoo Technologies".
Created attachment 63187 [details, diff] debianutils-2.14.1-no-bs-namespace.patch (+veto filenames beginning with period) Similar to attachment 63186 [details, diff] 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.
