Loading ...
Sorry, an error occurred while loading the content.

Fw: Polishing touch

Expand Messages
  • Mike Makonnen
    Hi Guys, What is happening below is that apm gets enabled and then the apmd script runs it again because the forcestatus for apm will always fail. So, it seems
    Message 1 of 3 , Jun 1, 2003
    • 0 Attachment
      Hi Guys,

      What is happening below is that apm gets enabled and then the apmd script
      runs it again because the forcestatus for apm will always fail. So, it seems
      that the way rc.d/apmd does its checking for apm is incorrect. There is no apm
      process to check for. Either the rc.d/apm script needs to have a working status
      command, or it should be turned into a .sh script and set an _apm_done variable
      for rc.d/apmd to check.

      Any ideas?

      Begin forwarded message:

      Date: 01 Jun 2003 18:45:49 +0200
      From: arno@...
      To: freebsd-current@...
      Subject: Polishing touch


      Hello,

      just in case re@ or a maintainer finds this worhtwhile :

      from my /etc/rc.conf :

      ifconfig_tap0="lladdr 00:90:27:3f:12:9f"
      apm_enable="YES"
      apmd_enable="YES"

      This gives me in dmesg-a (today's CVS) :
      [snip]

      2)

      NFS access cache time=2
      Starting usbd.
      > Starting apm.
      > Starting apm.
      Starting apmd.

      I somehow twice get 'Starting apm' ;


      --
      Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
      mtm@... | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
      mtm@...| FreeBSD - The Power To Serve
    • Simon L. Nielsen
      ... Actually a status for apm is quite simple... While I was looking at it I thought it would be nice to be able to stop apm also, so support for that is also
      Message 2 of 3 , Jun 1, 2003
      • 0 Attachment
        On 2003.06.01 20:09:20 -0400, Mike Makonnen wrote:

        > What is happening below is that apm gets enabled and then the apmd script
        > runs it again because the forcestatus for apm will always fail. So, it seems
        > that the way rc.d/apmd does its checking for apm is incorrect. There is no apm
        > process to check for. Either the rc.d/apm script needs to have a working status
        > command, or it should be turned into a .sh script and set an _apm_done variable
        > for rc.d/apmd to check.
        >
        > Any ideas?

        Actually a status for apm is quite simple... While I was looking at it I
        thought it would be nice to be able to stop apm also, so support for
        that is also included in the attached patch.

        --
        Simon L. Nielsen
      • Simon L. Nielsen
        ... But of course it wasn t that simple... When using forcestatus the rc script will always return 0, even when the the status function tries to return 1 to
        Message 3 of 3 , Jun 1, 2003
        • 0 Attachment
          On 2003.06.02 02:44:26 +0200, Simon L. Nielsen wrote:
          > On 2003.06.01 20:09:20 -0400, Mike Makonnen wrote:
          >
          > > What is happening below is that apm gets enabled and then the apmd script
          > > runs it again because the forcestatus for apm will always fail. So, it seems
          > > that the way rc.d/apmd does its checking for apm is incorrect. There is no apm
          > > process to check for. Either the rc.d/apm script needs to have a working status
          > > command, or it should be turned into a .sh script and set an _apm_done variable
          > > for rc.d/apmd to check.
          > >
          > > Any ideas?
          >
          > Actually a status for apm is quite simple... While I was looking at it I
          > thought it would be nice to be able to stop apm also, so support for
          > that is also included in the attached patch.

          But of course it wasn't that simple... When using forcestatus the rc
          script will always return 0, even when the the status function tries to
          return 1 to indicate that apm is not enabled. This is due to rc.subr
          ignoring the return value from the "user defined" functions, when run
          with run with the force prefix (if I read the code right).

          This can be handled, by making apmd check if there is output on stdout
          when apm forcestatus is run (not really right IMO), or by somehow making
          rc.subr not "hide" the return value from the status function. It can
          also be handled by using "exit 1" instead of "return 1" in the apm
          script, but I'm not really sure if that is "allowed" / correct.

          I'm rather unsure what the proper way to deal with this is.

          --
          Simon L. Nielsen
        Your message has been successfully submitted and would be delivered to recipients shortly.