Save logs to CIFS1, What am I doing wrong?

Discussion in 'Tomato Firmware' started by Jose C, May 6, 2019.

  1. Jose C

    Jose C Serious Server Member

    FreshTomato Firmware 2019.2 K26ARM USB AIO-64K

    bandwidth and ip traffics are succesffuly saving the logs to the cifs1, is just the logs that wont work, this is the configuration I have, can somebody help me to understand what is wrong?

    as soon as I set the /cifs1/ then logs go blank.

    remote log is working fine


  2. Jose C

    Jose C Serious Server Member

    **edit to fix image**
  3. eibgrad

    eibgrad Network Guru Member

    Just a guess at this point, but it might be a timing issue. It may be that the syslogd service is getting started before the cifs client gets connected, so it fails to run.

    Is the syslogd service actually running when this happens (check from a shell (telnet/ssh))?

    That's the problem sometimes when relying on external storage for internal processes.

    What you could try is (re)starting the syslogd service in the init script, but only once you've verified the cifs client is connected. Or the crude approach, just sleep a few seconds before (re)starting the syslogd service.
    Jose C likes this.
  4. Sean B.

    Sean B. Network Guru Member

    You have "custom log file path" and "remote logging" enabled at the same time. A cifs share is mounted locally, so uncheck the remote option. You also need to add the logfile name to the path, such as /cifs1/syslog.log . Make these changes when the cifs share is already mounted, as you can confirm it works. Then reboot and see if you hit problems, as the race condition @eibgrad mentioned is likely to occur.
    Jose C likes this.
  5. eibgrad

    eibgrad Network Guru Member

    Remote logging doesn't preclude local logging. They're not mutually exclusive.
    Jose C likes this.
  6. eibgrad

    eibgrad Network Guru Member

    P.S. If the Custom Log File Path needs a filename, seems to me it could use some rephrasing, because it sure sounds like it's only requesting a new path, and will use the default filename.

    Custom Log /Path/Filename

    Just tested it out, and it *does* require the full path + filename.
    Jose C likes this.
  7. Jose C

    Jose C Serious Server Member

    Hello, thanks for the help, it was the /cifs1/filename.log, as soon as I put the file name it started working, even after a reboot it works just fine.
  8. Sean B.

    Sean B. Network Guru Member

    I don't think the behavior of having both enabled is clearly defined in the code, though I'd have to look. Either way, I didn't say one would certainly break the other. Enabling both and pointing to the same share via 2 different paths is bad practice and asking for issues. On top of the fact using "remote logging" was not part of the OPs goal anyway.

    Also, although I'm not at home to access the router and check, I have a feeling if you check the notes section at the bottom of that page, you'll find more details on how to use a file path if you need them.
    Last edited: May 7, 2019
  9. eibgrad

    eibgrad Network Guru Member

    The OP has both remote logging and custom path specified. I had no reason to assume he didn't want both.

    The syslog path and remote logging serve different purposes. The former simply wants a path to a text file. It's usually local, whether internal to the router itself or perhaps a USB drive. The latter has its data sent to a *server*, presumably for parsing purposes and/or analysis by that server.

    Granted, in this particular case the OP happened to send both outputs to the same external device, so it seems a bit goofy at first blush. But as a general rule, it's perfectly valid and common to have the syslog written to a text file *and* pushed to a syslog server, at the same time. As I said, they aren't mutually exclusive.

    In the end, only the OP can tell us what are his true intentions.
  10. Sean B.

    Sean B. Network Guru Member

    I'm curious to give it a try, but I'd go as far as saying if the OP had put in a file name in his original configuration it would have resulted in errors on every log write, possibly file corruption. Syslogd would be trying to write to the same file under two different operations at the same time. Oplock would be a race condition to which one gets the file.
  11. eibgrad

    eibgrad Network Guru Member

    You're still not getting it (or else I'm missing your point).

    The OP eventually *did* provide a filename, and presumably kept remote logging enabled, and everything is functioning just fine.

    I fail to see a race condition here. When you configure syslogd, it will *always* write the log to a local *file* (or if you happen to map that local file to an external share, a remote file). Optionally, regardless of what you do w/ the file specification, you can *also* have the output sent to a *server* (NOT a file), which is typically done for debugging purposes. I often use this same technique when developing scripts, most recently using the Visual Syslog server.

    This server has nothing to do w/ the file to which the syslogd service writes its normal output. I'm sure the syslogd code works something like the following:

    write record to syslog local file
    if remote logging service is enabled, then
        # let server join in the fun!
        send record to server @ ip:port
    How could this cause a race condition? Neither output has any relationship to the other. The server is NOT writing to a file. If the server should decide to write its output to a file (perhaps for archival/replay/filtering purposes), it's certainly going to be a completely different file from the OP's own file on the share.
    Last edited: May 7, 2019
  12. Sean B.

    Sean B. Network Guru Member

    My bad, looked at the wrong screen shot and thought remote was the cifs UNC. IE: One writing with a network path destination, one writing to the local mount. Same destination/file, 2 paths.
  13. Jose C

    Jose C Serious Server Member

    The remote logging was sending logs to a sys log server in a Qnap device.

    The logs written to a text file are sent to another NAS in the network.

    In any case, everything is working as expected now. Thank you both for the help.

    Sent from my iPhone using Tapatalk
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice