On Linux, SQL Server configuration starts at a command line rather than Configuration Manager. The mssql-conf utility changes supported instance settings. Read the current file first and plan service restarts before applying a change.
Establish the Linux Prerequisites
This article is specifically for a supported SQL Server installation on Linux. It requires administrative access to that host and the installed configuration utility. The command examples belong on that Linux server, not in Windows PowerShell or an SSMS query window.
Every shell block is marked accordingly. The T-SQL checks can run from SSMS on Windows against the configured instance.
I read the active configuration before changing a setting. The file normally lives at /var/opt/mssql/mssql.conf. Settings not present there can still use engine defaults. The file isn't a complete dump of every T-SQL configuration.
Keep those layers separate. Save a local before-copy through your approved administration process and record which settings the maintenance change intends to alter. That makes reversal specific instead of hopeful.
# bash
sudo cat /var/opt/mssql/mssql.confSet the Process Memory Budget With mssql-conf
The memory.memorylimitmb setting controls memory available to the SQL Server process under this platform's configuration. The T-SQL max server memory setting controls a different engine memory boundary. Leave capacity for the operating system and other services.
A number suitable for one host isn't a universal recommendation. The example value below is a placeholder budget for an isolated configuration exercise, not a measured requirement.
The documented configuration change requires a service restart to apply. Schedule that restart before running the command on a shared host. Check the application's reconnect behavior afterward.
I evaluate both configuration layers when memory pressure is the concern. Raising the process budget without reviewing engine limits doesn't explain which allocation caused pressure. Conversely, a tight process limit can constrain the instance even when its buffer setting appears generous.
# bash
sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 8192
sudo systemctl restart mssql-serverPoint mssql-conf at New Default Paths
The filelocation.defaultdatadir and filelocation.defaultlogdir settings change default destinations for new database files. They don't move existing database files. Prepare the directories and service-account access first.
The sample uses separate new directories under the SQL Server area. Verify that the paths belong to the intended storage and have sufficient capacity. Different directory names can still share one volume and one bottleneck.
The restart applies the new defaults. Use the catalog afterward to inspect existing file paths separately. A defaults change and a physical file move are different maintenance tasks.
Don't rename or relocate active files with a shell command while the engine expects them at their old paths. Follow the supported database-specific move procedure and retain a recovery plan for any later relocation work.
# bash
sudo mkdir -p /var/opt/mssql/data-lab /var/opt/mssql/log-lab
sudo chown mssql:mssql /var/opt/mssql/data-lab /var/opt/mssql/log-lab
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /var/opt/mssql/data-lab
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /var/opt/mssql/log-lab
sudo systemctl restart mssql-server
Enable Agent Through mssql-conf With a Job Ownership Plan
The sqlagent.enabled setting controls SQL Server Agent through this utility. Enable it only when the deployment supports the required jobs and the team owns their behavior. Review schedules before restarting.
A newly active Agent can start enabled jobs according to their definitions. A service setup task shouldn't accidentally become the first execution of an unreviewed import or notification job.
The command below applies the setting with a restart. Check Agent status and the intended job history afterward. Job steps still need supported executables, permissions, and filesystem paths for this host.
A job copied from a Windows instance can contain Windows-specific commands that don't fit here. Enabling the scheduling service doesn't translate those steps or certify their dependencies. Rehearse the actual job path separately.
# bash
sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true
sudo systemctl restart mssql-serverChange the TCP Port With the Clients
The network.tcpport setting controls the listening port. A port change affects clients, monitoring, and approved network access rules. Update the endpoint configuration as part of the same maintenance plan.
The example port is a demonstration choice. Verify it is available and approved on the host before using it. A restart activates the change, so existing connection assumptions need a deliberate cutover.
Which application still relies on the old endpoint? Inventory that before the restart. Test a TCP connection using the new port from the required client location.
A successful local service start doesn't prove the network route works. Keep the previous value and a reversal procedure ready. The database can be healthy while every client continues knocking on a port the instance has stopped listening to.
# bash
sudo /opt/mssql/bin/mssql-conf set network.tcpport 51433
sudo systemctl restart mssql-serverManage Startup Trace Flags Deliberately
The traceflag subcommand enables or disables flags for service startup. Choose only documented flags that address an identified requirement. A flag isn't a substitute for understanding the diagnostic question.
The sample uses 1222 for deadlock detail in the error log. Review whether existing Extended Events capture already answers that question. Additional log output has a storage and review cost.
With mssql-conf, a restart applies the startup choice. Record the original state before enabling the flag, then reverse the experiment under another approved window if it isn't retained. Don't copy a list of flags from another instance without checking their purpose and version support.
A startup configuration should remain short enough that the next operator can explain every entry. Mystery numbers aren't a useful maintenance strategy.
# bash
sudo /opt/mssql/bin/mssql-conf traceflag 1222 on
sudo systemctl restart mssql-server
# Reversal for a later approved window:
# sudo /opt/mssql/bin/mssql-conf traceflag 1222 off
# sudo systemctl restart mssql-serverVerify the Effective State From Both Sides
Read the configuration file again and compare it with the planned changes. Use T-SQL to inspect engine settings and the connection's actual TCP port. Local or non-TCP connections can have a NULL port value, so test through the intended network route.
Check file paths with sys.master_files rather than assuming a new default moved old databases. Configuration and observed state need to agree under the relevant access path.
Use mssql-conf for supported platform settings and keep each restart visible in the maintenance plan. Change one related set at a time and validate application access afterward. Preserve the before-state for reversal.
A command returning successfully is the start of verification. The useful result is a running instance whose effective settings, clients, and jobs match the configuration you intended to deploy.
SELECT name,value_in_use FROM sys.configurations
WHERE name IN (N'max server memory (MB)',N'max degree of parallelism');
SELECT local_net_address,local_tcp_port
FROM sys.dm_exec_connections WHERE session_id = @@SPID;
SELECT DB_NAME(database_id) AS DatabaseName,name,physical_name FROM sys.master_files;Related reading on this blog: SQL Server on Linux: SQL in Sixty Seconds #162 and Connecting to SQL Server From Linux.
A configuration change is not an effective setting, it is a planned change followed by verification.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
