Unable to change debug flags in freetds.conf

[KarimElsayad247]

Before submitting an issue please check these first!

Environment

Operating System

• Running in a docker container

No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster
Linux example_app 5.19.0-41-generic #42~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 GNU/Linux

TinyTDS Version and Information

Compile-time settings (established with the "configure" script)
                            Version: freetds v1.1.24
             freetds.conf directory: /usr/local/etc
     MS db-lib source compatibility: no
        Sybase binary compatibility: no
                      Thread safety: yes
                      iconv library: yes
                        TDS version: 7.3
                              iODBC: no
                           unixodbc: no
              SSPI "trusted" logins: no
                           Kerberos: no
                            OpenSSL: yes
                             GnuTLS: no
                               MARS: yes

FreeTDS Version

freetds v1.1.24

Description

So I was trying to debug a particular issue, and for that I wanted to reduce the noise in freetds.log, and it didn't seem like my changes were picked up.

setting debug flags = 0x80 in /usr/local/etc/freetds.conf doesn't do anything, same with dump file

After some digging I found that TinyTDS simpley ignores freetds.conf, and changing anything there has no effect.

My question then becomes: how do I configure log level for freetds when I'm using tinytds?

[djberg96]

I'm having the same issue in a Rails app in a Kubernetes container. I've set TDSDUMP, FREETDS_DIR and FREETDS_CONF in the helm chart (which I can see are set in the console), and tried explicitly changing the version from 'auto' to 7.1, but it doesn't seem to change anything. I can see in tds.log:

log.c:187:Starting log file for FreeTDS 1.3.6
        on 2025-01-08 15:09:40 with debug flags 0x4fff.
dblib.c:1187:tdsdbopen(0x557dd312d510, ourdb.ourdb:1433, [microsoft])
dblib.c:1213:tdsdbopen: dbproc->dbopts = 0x557dd312eae0
dblib.c:1224:tdsdbopen: tds_set_server(0x557dd312d530, "ourdb.ourdb:1433")
dblib.c:251:dblib_get_tds_ctx(void)
dblib.c:1241:tdsdbopen: About to call tds_read_config_info...
config.c:170:Getting connection information for [cmm2.cmm2:1433].
config.c:174:Attempting to read conf files.
config.c:305:Found conf file '/etc/freetds/freetds.conf' (from $FREETDSCONF).
config.c:513:Looking for section global.
config.c:572:   Found section global.
config.c:575:Got a match.
config.c:598:   tds version = 'auto'
config.c:951:Setting tds version to auto (0x0).
config.c:572:   Found section egserver50.
config.c:572:   Found section egserver73.
config.c:586:   Reached EOF

I noticed that it seems to start the logging in 0x4fff, and never seems to pickup the change in the freetds.conf file.

Does a build option need to be passed in the Gemfile, or a Rails db config setting updated?

[andyundso]

sorry for the late reply.

@djberg96 the TDS version in the freetds.conf has no effect, because both tiny_tds and the activerecord-sql-adapter overwrite it. From activerecord-sql-adapter, I think you can change it using the database.yml by setting tds_version (see here). If you are using tiny_tds directly, you can pass it when creating the client instance with tds_version as well.

Please note that tiny_tds v3 and later will yell if you try to connect with TDS v7.2 and older. So you will need v2 to connect. But unless you connect to an ancient system (means 2008 and older), v7.3 is supported.

regarding the initial issue by @KarimElsayad247, I have to double-check, but usually you set the configuration location with FREETDS. tiny_tds does not overwrite anything there, because there is simply no option to do so.

[djberg96]

@andyundso We're using the activerecord sqlserver adapter (Rails 7.1 app btw), not tiny_tds directly. And I was just tinkering with the version based on your README, it didn't seem to have any effect anyway, so by default it's set to auto.

As for the location, it does seem to be picking it up as expected from FREETDSCONF and FREETDS_DIR. If there's some other env variable I should set, I'd be interested to know what it is.

Are you able to set a custom log file and reduct the logging level to something lower like 0x80? If so, how do you do it?

[andyundso]

... that kind of aligns with freetds that there are sometimes multiple options to achieve the same :)

to be honest, I did not play around with logging anything out of FreeTDS directly, but can do so in the next days.

Out of curiosity: What are you trying to solve / find out that you need extensive debug logs?

[djberg96]

I was getting strange database timeout errors and other oddities happening at one point in our kubernetes development cluster, and I wanted to see what the heck was happening under the hood. Since there was an option to specify an explicit tds log file, I added it to our helm chart.

But, the full logging is not that useful to me, way too much information, so I wanted to tone it down.

[andyundso]

@djberg96 @KarimElsayad247 I played around with the debug logs when invoking tiny_tds' tests. FREETDSCONF seems to pick up the freetds.conf, as you already reported.

$ FREETDSCONF=/tmp/freetds.conf bundle exec rake test

In this file I wrote:

[global]
dump file = /tmp/debug.log
debug flags = 0x601E

This gave me a log file with timestamps, network packages, from where things were called plus all errors and warnings:

15:43:39.708975 (token.c:2402):tds_process_info() reading message 5701 from server
15:43:39.709011 (token.c:2497):tds_process_info() calling client msg handler
15:43:39.709087 (token.c:2514):tds_process_info() returning TDS_SUCCESS
15:43:39.709116 (token.c:2230):tds_process_env_chg(): 5 bytes of collation data received
15:43:39.709141 (token.c:2231):tds->conn->collation was
0000 09 04 d0 00 34         -                        |....4|

So I say generally messing with the debug flags of FreeTDS should work. However, I would assume you need to restart your Rails app when changing values in the freetds.conf file.

@djberg96 if you need different information, this page lists the different Hex values what activates what and this page has a hex calculator to properly add things up.

[djberg96]

I think I tried setting it as low as 0x08 and it still seemed to be giving me full info. I tried restarting the rails server, but it had no effect. Maybe I need to restart the container.

[andyundso]

@djberg96 probably. Given that FreeTDS wrote one log file for my entire test, I would assume changes are only picked up when a new process spawns.

If that does not help, let me know. I can try to spin up a local app here with MSSQL to see if it behaves differently.

[djberg96]

At the moment within the Dockerfile I'm doing RUN sed -i 's/debug flags = 0xffff/debug flags = 0x08/g' /etc/freetds/freetds.conf as USER root after freetds-dev is installed, but before the Rails app starts.

[andyundso]

@djberg96 If I install freetds-dev into a plain debian:bookworm container, the debug flags line is commented out:

[global]
        # TDS protocol version
	tds version = auto

	# Whether to write a TDSDUMP file for diagnostic purposes
	# (setting this to /tmp is insecure on a multi-user system)
;	dump file = /tmp/freetds.log
;	debug flags = 0x08

so likely you need something like this:

sed -i 's/;\s*debug flags = 0xffff/\tdebug flags = 0x08/' /etc/freetds/freetds.conf

[andyundso]

I would recommend to copy the freetds.conf into the Docker container because I am not 100% sure how Docker build and shell escapes and all that stuff behaves together with the tab character in the regex.

[djberg96]

Ah, I didn't know the semicolons were also comment markers! I thought it was just some sort of newline delimiter.

However, even after removing them (as well as whatever example stuff it slapped in there), it still seems to be doing full logging. But, I also realized I don't know what sort of logging I should expect at different levels. I couldn't find any sample output for information level 1 vs information level 2 vs warning, etc.

[andyundso]

so I tried out customizing the debug logs with an app inside Docker. I used a toy application of mine, which was not meant to run with MSSQL (uses SQLite for the solid stack and virtual columns), but I managed to hack together something that runs in Docker.

The relevant commit where I passed the FreeTDS conf and customized the debug level is here.

and this works perfectly fine, warning level is really quiet:

app-1  | [161bb5fd-012a-4b07-9f95-7fdbbb51a237] Started GET "/uploads" for 172.20.0.1 at 2025-01-14 14:21:11 +0000
app-1  | [161bb5fd-012a-4b07-9f95-7fdbbb51a237] Processing by UploadsController#index as HTML
app-1  | 14:21:11.665663 59:Eating ORDERBY token
app-1  | 14:21:11.756333 59:Eating ORDERBY token
app-1  | 14:21:11.771403 59:Eating ORDERBY token
app-1  | 14:21:11.925623 59:Eating ORDERBY token
app-1  | [161bb5fd-012a-4b07-9f95-7fdbbb51a237]   Rendered layout layouts/application.html.haml (Duration: 117.5ms | GC: 0.0ms)
app-1  | [161bb5fd-012a-4b07-9f95-7fdbbb51a237] Completed 200 OK in 521ms (Views: 116.9ms | ActiveRecord: 321.7ms (3 queries, 0 cached) | GC: 4.9ms)

so I conclude, that passing a custom freetds.conf file to change the debug flags works as expected, even in Docker.