cannot write logfile Error 1059 : Circular service dependency

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • donnyma@fastmail.fm

    cannot write logfile Error 1059 : Circular service dependency

    I have a problem that looks like it has not been discussed before in
    these groups.

    I have a simple SQLAgent job that runs sp_who (could be anything, but
    let's just say sp_who for this example). I have set the jobstep to
    write to an output file "T:\out.txt ". If the job is owned by an
    admin, it runs fine and writes the output file. If it is owned by a
    non-admin user, it gets the following error msg:

    Warning: cannot write logfile t:\out.txt. Error 1059 : Circular
    service dependency was specified. The step failed.

    I know about setting up the SQLAgent CMDExec proxy account, and have
    done that. In fact, both SQLAgent and the SQLAgent cmdexec proxy use
    the same domain account, which is in the administrator group of the
    local server. So, I know that security is not the issue.

    When a simple job runs and writes to an output file, what service or
    service group could it be trying to start or modify? I looked through
    the list of Services, and could not find any circular dependencies.
    Is there a utility to detect this? Why would running under one
    context (as an admin) be ok while the other context (non-admin on SQL,
    but using the same admin domain service account) fails?

    Thanks in advance for any info you might have.

  • Steve

    #2
    Re: cannot write logfile Error 1059 : Circular service dependency

    On Feb 13, 6:33 pm, donn...@fastmai l.fm wrote:
    I have a problem that looks like it has not been discussed before in
    these groups.
    >
    I have a simple SQLAgent job that runs sp_who (could be anything, but
    let's just say sp_who for this example). I have set the jobstep to
    write to an output file "T:\out.txt ". If the job is owned by an
    admin, it runs fine and writes the output file. If it is owned by a
    non-admin user, it gets the following error msg:
    >
    Warning: cannot write logfile t:\out.txt. Error 1059 : Circular
    service dependency was specified. The step failed.
    >
    I know about setting up the SQLAgent CMDExec proxy account, and have
    done that. In fact, both SQLAgent and the SQLAgent cmdexec proxy use
    the same domain account, which is in the administrator group of the
    local server. So, I know that security is not the issue.
    >
    When a simple job runs and writes to an output file, what service or
    service group could it be trying to start or modify? I looked through
    the list of Services, and could not find any circular dependencies.
    Is there a utility to detect this? Why would running under one
    context (as an admin) be ok while the other context (non-admin on SQL,
    but using the same admin domain service account) fails?
    >
    Thanks in advance for any info you might have.
    Googling it returns:
    Circular service dependency was specified.
    Explanation:
    An application tried to change the service dependency list for a
    service. A check of the other service dependency lists in the service
    database reveals at least one circular relationship between the
    proposed new list and existing lists. For instance, service A must
    start before service B in one list, but service B must start before
    service A in another list. Your computer has not been configured
    properly.

    Do both accounts have the same permissions to the directory the file
    is output to?




    Comment

    • Donny Ma

      #3
      Re: cannot write logfile Error 1059 : Circular service dependency

      There is really only one account, because both SQLAgent and SQLAgent
      cmdexec proxy (which is what is used when a non-admin runs a job)
      both use this account, which is an admin on the local server. So,
      yes, they both have the same permissions. SQLAgent seems to be trying
      to start or modify some other service. I looked through services, and
      could not find any circular dependencies.


      On Feb 13, 9:48 pm, "Steve" <morrisz...@hot mail.comwrote:
      Googling it returns:
      Circular service dependency was specified.
      Explanation:
      An application tried to change the service dependency list for a
      service. A check of the other service dependency lists in the service
      database reveals at least one circular relationship between the
      proposed new list and existing lists. For instance, service A must
      start before service B in one list, but service B must start before
      service A in another list. Your computer has not been configured
      properly.
      >
      Do both accounts have the same permissions to the directory the file
      is output to?>



      Comment

      • Donny Ma

        #4
        Re: cannot write logfile Error 1059 : Circular service dependency

        Has anyone run into this problem??

        I have a simple SQLAgent job that runs sp_who (could be anything, but
        let's just say sp_who for this example). I have set the jobstep to
        write to an output file "T:\out.txt ". If the job is owned by an
        admin, it runs fine and writes the output file. If it is owned by a
        non-admin user, it gets the following error msg:


        Warning: cannot write logfile t:\out.txt. Error 1059 : Circular
        service dependency was specified. The step failed.


        I know about setting up the SQLAgent CMDExec proxy account, and have
        done that. In fact, both SQLAgent and the SQLAgent cmdexec proxy
        use
        the same domain account, which is in the administrator group of the
        local server. So, I know that security is not the issue.


        When a simple job runs and writes to an output file, what service or
        service group could it be trying to start or modify? I looked
        through
        the list of Services, and could not find any circular dependencies.
        Is there a utility to detect this? Why would running under one
        context (as an admin) be ok while the other context (non-admin on
        SQL,
        but using the same admin domain service account) fails?


        Thanks in advance for any info you might have.



        Comment

        Working...