Bug 197552 - sysutils/fsc: Creates a circular rcorder dependency.
Summary: sysutils/fsc: Creates a circular rcorder dependency.
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Tobias Kortkamp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-12 00:54 UTC by Duane
Modified: 2018-11-08 14:30 UTC (History)
5 users (show)

See Also:
w.schwarzenfeld: maintainer-feedback-


Attachments
svn-diff_sysutils_fsc (909 bytes, patch)
2018-01-15 01:17 UTC, Walter Schwarzenfeld
no flags Details | Diff
Patch to remove NETWORKING condition from fscd rc script (502 bytes, patch)
2018-01-16 10:01 UTC, Ben Woods
woodsb02: maintainer-approval? (trhodes)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Duane 2015-02-12 00:54:56 UTC
The rc.d/fscd requires DAEMON before NETWORKING which creates a circular dependency and breaks system boot.

pkgsrc resolved this issue in version 1.1 in late 2012 by removing the NETWORKING before dependency.

It's a little bit sad that the NetBSD port of the 'FreeBSD Service Check Daemon' works better than the FreeBSD port.  How much longer until FreeBSD gives up on its own ports system and gets behind one that works?
Comment 1 Bugzilla Automation freebsd_committer 2015-02-12 00:54:56 UTC
Auto-assigned to maintainer trhodes@FreeBSD.org
Comment 2 Walter Schwarzenfeld freebsd_triage 2018-01-09 00:16:19 UTC
rc.d/fscd has
# PROVIDE: fscd
# REQUIRE: DAEMON syslogd
# BEFORE:  NETWORKING LOGIN
# KEYWORD: shutdown

so I guess it is done, and could be closed.
Comment 3 Duane 2018-01-14 22:36:06 UTC
(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?
Comment 4 Walter Schwarzenfeld freebsd_triage 2018-01-14 23:46:45 UTC
If I change to
# PROVIDE: fscd
# REQUIRE: NETWORKING syslogd
# BEFORE:  DAEMON LOGIN
# KEYWORD: shutdown

seems to work.
Comment 5 Duane 2018-01-15 00:23:26 UTC
(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?
Comment 6 Walter Schwarzenfeld freebsd_triage 2018-01-15 00:33:18 UTC
I think it this here:

/etc/rc.d/DAEMON

# PROVIDE: DAEMON
# REQUIRE: NETWORKING SERVERS
Comment 7 Duane 2018-01-15 00:49:19 UTC
(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.
Comment 8 Walter Schwarzenfeld freebsd_triage 2018-01-15 01:17:20 UTC
Created attachment 189729 [details]
svn-diff_sysutils_fsc
Comment 9 Walter Schwarzenfeld freebsd_triage 2018-01-15 01:18:00 UTC
Why simple if there's a complicated way? You're right.
Comment 10 Alfred Perlstein freebsd_committer 2018-01-16 05:28:39 UTC
Does it make sense to add some kind of post-install step for ports to check for this problem?

cc: @trhodes
Comment 11 Duane 2018-01-16 05:38:45 UTC
(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.
Comment 12 Alfred Perlstein freebsd_committer 2018-01-16 06:52:05 UTC
Sounds like it could be checked in two places:

1. post-pkg-install and post-ports-install
2. /etc/periodic/daily
Comment 13 Ben Woods freebsd_committer 2018-01-16 10:01:55 UTC
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.
Comment 14 Tobias Kortkamp freebsd_committer 2018-11-07 12:14:32 UTC
(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.
Comment 15 Walter Schwarzenfeld freebsd_triage 2018-11-07 12:41:04 UTC
Reset maintainer.
Comment 16 Walter Schwarzenfeld freebsd_triage 2018-11-07 13:00:07 UTC
@tobik or @ben please, commit it (otherwise it will be open till the end of time).
Comment 17 Tobias Kortkamp freebsd_committer 2018-11-07 21:50:49 UTC
(In reply to w.schwarzenfeld from comment #16)
I cannot reproduce the problem, so I am the wrong guy to do it.
Comment 18 commit-hook freebsd_committer 2018-11-08 12:01:11 UTC
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
Comment 19 commit-hook freebsd_committer 2018-11-08 13:50:42 UTC
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
Comment 20 Walter Schwarzenfeld freebsd_triage 2018-11-08 14:30:13 UTC
Thank you!