NOTES.INI debugging-type variables

本文介绍了多种调试参数设置,如Debug_Outfile、Debug_ThreadID等,用于捕捉服务器控制台信息及特定功能的日志,帮助诊断和解决问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Debug_Outfile
The Debug_Outfile setting allows you to create a more complete debugging log by capturing information sent to the server console. Its syntax is:


Debug_Outfile=
filename

Depending on what type of problem your server is experiencing, you use the Debug_Outfile parameter in conjunction with appropriate debugging parameters. For example, if you are having semaphore timeout issues, you would want to turn on semaphore debugging:


Debug_ThreadID=1
Debug_Capture_Timeout=1
Debug_Show_Timeout=1


Adding these parameters to NOTES.INI results in additional information being sent to the server console, but not to the Notes log file (log.nsf). To capture a history of what appears on the console, you need to add the Debug_Outfile parameter to NOTES.INI, as in the following example:


Debug_Outfile=C:/TEMP/DEBUG.TXT
Debug_ThreadID=1
Debug_Capture_Timeout=1
Debug_Show_Timeout=1


Note that Debug_Outfile can be at either the beginning of your debugging parameters or at the end; it is important, however, to insert a carriage return after the last NOTES.INI entry.


When you specify the path for the debug file in Debug_Outfile, the directory must already exist; Notes will not automatically create the directory for you. Also, it is strongly recommended that the Debug_Outfile parameter be configured to save the log file in a location that is isolated from the partition where the operating system, Domino server, and other applications may potentially create files that are necessary for those programs to function correctly (for example, SWAP files, data files, and so on). Placing the log file on an isolated partition avoids any potential problems.


When the log file is placed on an isolated partition not being used by any currently running applications, if that partition runs out of disk space, the Domino server will stop logging to the file specified in the Debug_Outfile parameter. With no disk space to write the log file to, the Domino server's overall performance is not affected and it continues to function. If some hard drive space is cleared, the server will continue to add entries to the log file specified in the Debug_Outfile parameter. Be aware that this log file may grow significantly in size over a period of time on a Domino server that has a high rate of activity. The log file cannot be deleted while the Domino server is running; if an attempt is made to delete the file, a sharing violation will occur.


Once the Debug_Outfile parameter has been added to the NOTES.INI file, the Domino server must be shut down and restarted for logging to begin. Also be aware that, even though the Domino server has been restarted, the log will not be written if the server's Notes client has been left running.


Debug_Directory_Assistance and Debug_NameLookup

When using Directory Assistance, including LDAP (which is configured to use a Master Address Book), you can add the following lines in the NOTES.INI file of the server that is using Directory Assistance, in order to supply more than the usual amount of information:


Debug_Directory_Assistance=1
Debug_NameLookup=1


Remember to add the Debug_Outfile parameter to capture the data. We recommend that these parameters be run separately to make the data easier to view.


Note:
When these parameters are placed within the server's NOTES.INI file, the server must be cycled for the changes to take effect.

Debug_AdminP

The Debug_AdminP setting lists AdminP schedule information. When Debug_AdminP=1, AdminP will dump out its schedule information every time the schedule is updated.


Remember, you will also need to provide the Debug_Outfile parameter to capture a history of what appears on the console. The Debug_AdminP setting is only available on R5 servers.


Debug_Repl_All

Debug_Repl_All allows you to view the order (or sequence) in which documents are replicated in a Notes database. When there is no sort order in a view column in a Notes database, documents are sorted/replicated in order of NoteID.


Debug_Repl_All=1 gives information for each document that is replicated, for example:


10-12-94 08:43:19 AM REPLICA: Updating NoteID 0x216E in Discuss.nsf
10-12-94 08:43:19 AM REPLICA: Deleting NoteID 0x2162 in Discuss.nsf


Debug_Repl_All=2 provides information for each document that is not replicating, for example:


10-12-94 05:31:00 AM REPLICA: ...Skipping note in Destination list (UNID OFCCADF6EB:E1B3F184-ON852560A6:OF2867N9P3)

10-12-94 05:31:00 AM REPLICA: ...(Con't) Destination has same or newer note. Src Time/SeqNo=10-11-94 05:31:00 AM
10-12-94 05:31:00 AM REPLICA: ...Skipping note in Destination list (UNID OF282B7FF5:B72B7102-ON852560A6:OF2867N9P3)


Either Debug_Repl_All setting lets you see the order of replication. (Note that this order will be different in every replica copy of the database.) Remember to use Debug_Outfile to display the list of documents.


Debug_Btree_Errors

The Debug_Btree_Errors setting was enabled as a default NOTES.INI setting in release 5.0.5 to capture additional information when Btree corruption occurs. The intent was to obtain relevant information when Btree corruption occurred instead of having to set it and wait for the issue to occur again. Although this parameter has not been put into the NOTES.INI file on a fresh install of 5.0.6a or later, if a customer previously installed 5.0.5 and does an incremental upgrade to 5.0.6a or later, the setting will remain.


The Debug_Btree_Errors=1 setting displays Btree error messages on the server console. If there is a significant time lapse between a Btree error being detected and the user noticing the error message on the console (as may happen if the error occurs overnight), the only troubleshooting information available is the current error message on the console.


Note:
If the Debug_Btree_Errors parameter is in your NOTES.INI file, you may want to remove it. When this parameter is enabled (set to 1), you may receive a large number of Btree error messages displayed on the server console. In many cases, these Btree errors are informational only, and you will not need to capture additional information about them.

Debug_FTV_Search

You can use the setting Debug_FTV_Search=1 to capture an end-user's keyword searches. If you want to capture the searches on a server database, use the server's NOTES.INI file; to capture the searches on a local database, use the Notes client's NOTES.INI file. Remember to use Debug_Outfile to properly capture the information.


Here is an example of the output from Debug_FTV_Search:


API handle obtained in 49 ms.
Query: (TIME)
Verity Query: (<MANY><STEM>`TIME`)
Setup for retrieval in 43 ms.
Retrieval performed in 7 ms. 7 documents found
Built result tables (incl. refinement) in 2 ms. 6 documents Left
Total search time 101 ms.


Debug_AMGR

Debug_AMGR is a setting that allows the Domino server to report Agent Manager (AMGR) activities. As of the Domino 4.6.1 server, the server will also record AMGR activity for databases that do not contain agents, when those databases have new documents added to them, existing documents are modified, or new mail is delivered to them.


Keep in mind that it is the activity itself that AMGR is reporting; it is not necessarily reporting that an agent will be executed as a result of an activity. So even if there are no agents in the database, AMGR may report that an activity occurred in that database.


The following table describes which Debug_AMGR flags can be set:



FlagDescription
cTo output agent control parameters
eTo output information about Agent Manager events (new in 4.6.1)
lTo output agent loading reports
mTo output agent memory warnings
pTo output agent performance statistics
rTo output agent execution reports
sTo output information about AMGR scheduling
vVerbose mode, which outputs more messages about agent loading, scheduling, and queues
*To output all of the above


The NOTES.INI setting Debug_AMGR=* will generate a large amount of extraneous information. Therefore, to limit the amount of information returned by AMGR, do not use the * (asterisk) flag. Instead, use only the flag that you need for troubleshooting.
 
<think>嗯,用户想在Windows的CMD中启动Chrome浏览器,同时指定远程调试端口和用户数据目录。我需要回忆一下相关的命令行参数。根据之前的引用,用户提到过使用类似`chrome.exe --remote-debugging-port=9222`的命令,所以端口参数应该是正确的。 接下来是用户数据目录的设置。我记得Chrome有一个`--user-data-dir`参数,后面需要跟上路径。比如`--user-data-dir=C:\MyChromeProfile`。这样就能指定存储用户数据的位置,避免和默认的配置冲突。 然后需要组合这两个参数。正确的命令应该是同时指定端口和用户目录。比如: `chrome.exe --remote-debugging-port=9222 --user-data-dir="C:\MyChromeProfile"` 不过要注意路径中的空格,最好用双引号括起来。用户可能在使用自定义路径时有空格,所以引号是必要的。比如路径中有空格的话,不加引号可能会导致命令解析错误。 另外,用户提到的引用[2]里提到远程调试需要电脑端的Chrome版本高于安卓端,不过这里用户可能只是在Windows上使用,所以可能不需要考虑跨设备的问题,但版本兼容性还是需要注意,比如确保Chrome版本支持这些参数。 还有,用户数据目录如果不存在的话,Chrome会自动创建吗?应该会的,但用户需要确保有写入权限。可能需要提醒用户检查目录权限,或者确保路径正确无误。 最后,验证这个命令是否正确。启动Chrome后,可以通过访问`http://localhost:9222`来检查远程调试是否生效。同时查看用户数据目录是否生成新的文件,确认配置正确。 总结一下,步骤应该是: 1. 打开CMD。 2. 切换到Chrome的安装目录,或者直接使用完整路径调用chrome.exe。 3. 执行命令,包含两个参数:端口和用户数据目录。 4. 验证是否成功。 可能的问题点:用户可能没有关闭所有Chrome实例,导致端口被占用。需要确保Chrome完全退出后再执行命令。或者用户路径中有特殊字符,需要用正确的引号处理。 另外,引用[3]提到的UNC路径和DNS相关的内容可能不适用于这个问题,但用户的问题主要是命令行参数,所以可以忽略这部分。</think>在Windows命令行CMD中启动Chrome浏览器并指定远程调试端口及用户数据目录的步骤如下: ### 操作步骤 1. **关闭所有Chrome实例** 执行命令前需确保所有Chrome进程已终止(通过任务管理器或`taskkill /f /im chrome.exe`) 2. **构建命令参数** 使用以下格式组合参数: ```cmd chrome.exe --remote-debugging-port=端口号 --user-data-dir="用户数据目录路径" ``` - `--remote-debugging-port=9222`:设置远程调试端口为9222[^1] - `--user-data-dir="C:\MyChromeProfile"`:指定用户数据存储路径(路径含空格时需加引号) 3. **完整命令示例** ```cmd "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="D:\ChromeDebugProfile" ``` ### 注意事项 - 若使用网络隔离环境,可通过DNS信道传递数据(参考UNC路径原理[^3]) - 建议使用Chrome Canary版本以获得更好的兼容性[^2] - 端口号需未被其他程序占用 - 用户数据目录建议使用全新空文件夹
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值