Bug 197552
| Summary: | sysutils/fsc: Creates a circular rcorder dependency. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Duane <parakleta> | ||||||
| Component: | Individual Port(s) | Assignee: | Tobias Kortkamp <tobik> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Many People | CC: | alfred, pi, trhodes, w.schwarzenfeld, woodsb02 | ||||||
| Priority: | --- | Flags: | w.schwarzenfeld:
maintainer-feedback-
|
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Duane
2015-02-12 00:54:56 UTC
Auto-assigned to maintainer trhodes@FreeBSD.org rc.d/fscd has # PROVIDE: fscd # REQUIRE: DAEMON syslogd # BEFORE: NETWORKING LOGIN # KEYWORD: shutdown so I guess it is done, and could be closed. (In reply to w.schwarzenfeld from comment #2) Um, NO? The problem is exactly that it requires DAEMON before NETWORKING. Install `sysutils/fsc` and then run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/fscd` and see what happens. I should apologise for my hostility when I reported the bug but it had been a nightmare to discover why my system was randomly failing to initialise some services at boot, and then to discover it was due to a bug that had been fixed so long ago elsewhere was frustrating. This bug continues more than 5 years after it was solved elsewhere, and nearly 3 years after it was reported here, and it breaks system boot which seems a critical failure to me. Maybe this port should just be removed from the ports system until it is actually safe to use? If I change to # PROVIDE: fscd # REQUIRE: NETWORKING syslogd # BEFORE: DAEMON LOGIN # KEYWORD: shutdown seems to work. (In reply to w.schwarzenfeld from comment #4) Sure, but now you've changed two elements of the dependency ordering. Is there a rationale for both of those changes? I think it this here: /etc/rc.d/DAEMON # PROVIDE: DAEMON # REQUIRE: NETWORKING SERVERS (In reply to w.schwarzenfeld from comment #6) But why should the service be changed from "REQUIRE: DAEMON" to "BEFORE: DAEMON"? This significantly changes the order of a service that manages other daemons. A sufficient fix, and the one that was applied to NetBSD in 2012, and that I proposed in the initial report, is simply to remove the "BEFORE: NETWORKING" dependency and leave the others untouched. I can see no rationale for why this service would need to be initialised before networking is initialised and so I propose that this is the only dependency in error. Created attachment 189729 [details]
svn-diff_sysutils_fsc
Why simple if there's a complicated way? You're right. Does it make sense to add some kind of post-install step for ports to check for this problem? cc: @trhodes (In reply to Alfred Perlstein from comment #10) There are three places I think where this can be checked. I think it is definitely a MUST that as part of the ports development process they are checked against `/etc/rc.d/*` for trivial breakages. They SHOULD also probably be tested in something like poudriere (i.e. a clean sandbox) against both `/etc/rc.d/*` and `/usr/local/etc/rc.d/*` to check for breakages with the core system and the dependencies pulled in by the port. These two tests would have caught the two bugs I have filed with this problem. A much more difficult problem is transitive ordering problems with unrelated (dependency-wise) ports. This can only be tested on each individual machine after installing ports or packages and provide a warning to the user. Alternatively something like a pre-shutdown sanity check if any ports/packages have been changed but this probably isn't enough. I'm not sure how best to protect in this case, but it's pretty bad if you update or install a package, restart the associated service and carry on, and then 3 months later a power failure causes your machine to reboot and it fails to start properly because the rcorder was broken. Sounds like it could be checked in two places: 1. post-pkg-install and post-ports-install 2. /etc/periodic/daily Created attachment 189789 [details]
Patch to remove NETWORKING condition from fscd rc script
Walter's patch seemed to be malformed. I believe this patch reflects the change he was trying to make (simply remove NETWORKING from the rc script).
Waiting for Tom's approval as maintainer.
(In reply to Ben Woods from comment #13) Maintainer timeout of > 9 months now if you or anyone else wants to land it. Also reason enough for a maintainer reset. Reset maintainer. @tobik or @ben please, commit it (otherwise it will be open till the end of time). (In reply to w.schwarzenfeld from comment #16) I cannot reproduce the problem, so I am the wrong guy to do it. A commit references this bug: Author: tobik Date: Thu Nov 8 12:00:58 UTC 2018 New revision: 484445 URL: https://svnweb.freebsd.org/changeset/ports/484445 Log: sysutils/fsc: Avoid circular dependency in rc script rcorder: Circular dependency on provision `DAEMON' in file `/usr/local/etc/rc.d/fscd'. - Reset maintainer due to the long timeout PR: 197552 Reported by: parakleta@darkreality.org Approved by: trhodes (maintainer timeout, 3.5 years) Obtained from: pkgsrc Changes: head/sysutils/fsc/Makefile head/sysutils/fsc/files/patch-rc.d_fscd A commit references this bug: Author: tobik Date: Thu Nov 8 13:50:21 UTC 2018 New revision: 484455 URL: https://svnweb.freebsd.org/changeset/ports/484455 Log: MFH: r484445 sysutils/fsc: Avoid circular dependency in rc script rcorder: Circular dependency on provision `DAEMON' in file `/usr/local/etc/rc.d/fscd'. - Reset maintainer due to the long timeout PR: 197552 Reported by: parakleta@darkreality.org Approved by: trhodes (maintainer timeout, 3.5 years) Obtained from: pkgsrc Approved by: ports-secteam runtime fix blanket Changes: _U branches/2018Q4/ branches/2018Q4/sysutils/fsc/Makefile branches/2018Q4/sysutils/fsc/files/patch-rc.d_fscd Thank you! |
