1.问题：
通过 FTP 连续上传 100 个或更多文件时发生中断。行为异常。在 2011 年的新 PC 上，Ubuntu 刚刚安装。Ubuntu 没有其他问题。浏览器操作和网站加载速度很快。
问题除了下面描述的步骤之外，我还能尝试什么？
或者是否存在原始错误或原始解决方案？
原文未修改。更新内容包括：
- 2011年12月7日：在3.2中添加以下信息）
- 2011年12月9日：新增：4.d) 4.e)
- 2011年12月10日：新增4.f)
2.更多事实：
FTP 上传数千个文件（多个网站）由自己的 Perl 程序完成，这些程序向 LINUX 系统的标准 ftp 发送一系列 FTP 标准命令。效果：类似于镜像 - 但可以进行微调。
使用的单个命令“ftp mput”包含例如 100 个文件，每个文件约 100 KB。每个网站约 1000 个文件。
上传至：使用共享主机的网站。服务器使用 Linux，例如 Bluehost=Hostmonster 或 Lunarpages。
3.1)到目前为止我从未遇到过这样的问题。
多年来，我从未遇到过 Fedora 这样的问题。2006 年 PC 上的 Fedora 13 至今仍能正常工作（相同的 DSL 连接，相同的 DSL 硬件）。我故意没有升级 Fedora 13。因此，LINUX ftp 在此期间可能有所改变。但这不太可能是原因。
PC 仅用作操作系统供应商。数据和自带软件位于外部硬盘上，独立于操作系统且可移植（由 Perl 软件组织）。
新的 UBUNTU PC 在相同的外部硬盘和相同的软件环境下工作时不能完美地完成这项工作。
（只有网线不同，但这不会造成任何问题。旧的 FEDORA PC 长度为 1 米，新的 Ubuntu PC 长度为 5 米。）
3.2) UBUNTU 特性可能导致问题 (2011 年 12 月 7 日添加)
与此同时/现在我有：
UBUNTU 64b 从 2011 年底开始出现在新 PC/2011、SATA 硬盘上。
从 2011 年底开始，UBUNTU 32b 就出现在旧 PC / 2006、PATA（/IDE）硬盘上。
这些只是操作系统的供应商。所有数据、软件和执行都在外部硬盘上完成，这两种情况都是相同的。
两种情况下，都会发生所述问题。在旧 PC 上运行 Fedora 13（大约从 2009 年开始）时不会发生此问题。
因此，该问题很可能与 UBUNTU 的特定功能有某种关联。
有极小概率是自从FEDORA 13开始通用LINUX系统发生了改变，导致出现此问题。
通过快速的 Google 搜索，到目前为止我还没有找到有关类似问题的任何信息。
UBUNTU 的其他所有功能在新的宽屏 PC 上运行良好。因此，从现在起，选择权暂时在这里。
这几周我获得了 10 倍速度的 DSL 互联网连接。也许问题会消失。（我想它不会消失。）
4.a) 设定优先级没有帮助。
使用 nice 命令，我测试了优先级 -18（已在 gnome-system-monotor 中验证 - 是的，-18）。这没有帮助。
4.b）使用 sudo 没有帮助
我还尝试使用 sudo 调用执行该作业的 Perl 程序。这不会影响结果。
4.c) 行为异常
没有规定在什么时候（哪个文件）停止上传。通常是几分钟后——只有一次它完成了整个 2 小时的工作。可能与互联网使用高峰时段有轻微的关联。但这不确定。
4.d) 没有来自以下方面的帮助：源代码、-i 标志、-v 标志（2011 年 12 月 9 日添加）
所涉及的完整的长 Perl 程序在这里不会有帮助。（各种功能、站点、细节……）。
这里是带有上传问题的 OWN 命令（Perl 子程序）（示例）：
&FTP_c_mput (" www/ppp-de/*.htm")
这只是执行 FTP 命令：mput www/ppp-de/*.htm
大约 200 个文件，但问题出在第 30 个文件左右
-i 全部是自动的 - 因此已经带有 -i 标志，因此没有任何交互。因此通常不会发生超时错误。
-v --- 始终处于详细模式（因此结果在 nr.5.2. 和 5.3.）
我仍然需要在软件中实现调试功能 -d（如推荐的那样）。但它是否有帮助还不得而知 - 因为……：
4.e) 最可能的问题原因 - 我认为 (添加于 2011 年 12 月 9 日)
最有可能的是，Ubuntu 特有的某些进程造成了延迟 - 因此 ftp 程序无法足够快地向远程 PC（Internet 服务器）提供下一个文件。但我没有说明任何其他功能有几秒钟的延迟。一切都运行完美且快速。在问题发生之前，我找不到任何软件操作的关联。
我声明，每隔 3 秒就会出现一次短暂的硬盘访问（如果控制 led 正常运行）。每隔 3 秒 - 或更快。不规律。这可能有简单的解释。即使在没有应用程序运行时，这种情况也会继续 - 显示器完全空白。但我不认为原因与此有关。
4.f) 调试功能？ftp -d（2011 年 12 月 10 日添加）
ftp 的 -d 标志：尚未尝试（但有评论推荐）。
仅使用 -d 标志是不够的。要记录 ftp，需要执行各种步骤（rsyslog.conf...）。对于此类问题，投入这些时间取得成功的可能性接近于零。
因此，我将继续采用变通方法：在 Fedora（= PC 1）上进行批量上传，在 Ubuntu（= PC2）上进行其余操作，并尝试其他步骤，以便在未来找到解决方案。
5.1. 示例：这是上传过程中的控制显示
此显示由我自己的 Perl 程序完成，因此不是通过 FTP 完成的。已缩短。可能包括 100...300 个文件。
www/xmed-ppp-de/index.htm www/xmed-ppp-de/wweb-pare-med-de.htm www/xmed-ppp-de/wwee-fina-med-de.htm www/xmed-ppp-de/wwfu-cont-med-de.htm www/xmed-ppp-de/wwfu-sepa-med-de.htm
5.2. 例如：ftp 程序的标准显示如下：
150 连接到端口 63555
#...
226-文件传输成功
226 7.126 秒（此处测量），每秒 10.14 千字节
0.81 秒内发送了 73985 字节 (89.7 kB/s)
本地：www/xmed-ppp-de/wyck-tob-bo-med-de.htm 远程：www/xmed-ppp-de/wyck-tob-bo-med-de.htm
200 PORT 命令成功
5.3. 例：中断时的显示：
在新电脑上安装 UBUNTU 后，该系列在约 30 个文件后基本结束，在 20 到 50 个之间随机变化，并出现以下错误消息： - 因此：我的打字出现超时错误 - 但这是 FTP 批量命令 mput， - 所以我的电脑上不可能存在打字速度问题......
150 连接到端口 63562
#...
226-文件传输成功
226 10.317 秒（此处测量），每秒 14.02 千字节
6.65 秒内发送了 148068 字节（21.8 kB/s）
本地：www/xmed-ppp-de/wyck-tob-ris-med-de.htm 远程：www/xmed-ppp-de/wyck-tob-ris-med-de.htm
200 PORT 命令成功
421 超时 - 下次尝试输入快一点
本地：www/xmed-ppp-de/wyck-tob-sto-med-de.htm 远程：www/xmed-ppp-de/wyck-tob-sto-med-de.htm
没有命令的控制连接：成功
本地：www/xmed-ppp-de/wycu-nut-med-de.htm 远程：www/xmed-ppp-de/wycu-nut-med-de.htm
........... 等等。对于以下所有文件............
答案1
（这是我对上述问题的回答。）
解决方案是：
使用更快的互联网连接时，此问题不再发生。
其发生速度为 0.2 Mb/秒（过去的 DSL 上传标准速度 - 与 2005、2006 年的水平相同；未测量）。
对于 1.2 Mb/秒或类似的速度，这种情况不再发生（当前上传速度，通过移动互联网接入 UMTS，用http://www.umts-speedtest.com）
如果这种移动接入方式（UMTS）网速降低，问题又会出现。这种情况可能出现在移动接入网络上网的每日高峰时段。
在接下来的几周内，这里的网速将提高到 5 Mb/秒（上传速度为 25 或 50）。因此，这很可能可以彻底解决问题。
现在我们对问题原因有了很好的定义：
该问题类型仅发生在使用的 UBUNTU 发行版 DVD/2011 年末（但可能发生在所有当前的 UBUNTU 发行版中）。
Fedora Core 从未出现过此问题，至少在 13=2009 版本之前没有出现过。后续版本尚未检查。据推测后续版本和当前版本（2011、2012）的 Fedora Core 也不会出现此问题。
问题并不重要。为上传速度较慢的用户（2005 年左右的典型情况）进行这种批量上传工作并不常见。
除错：有 Bug 吗？
FTP 实用程序可能以不同的方式进行批量上传，因此可能不会受到影响。问题可能仅在使用基本 FTP 命令（mput）进行 30++ 个文件批量上传时才会发生
此命令适用于所有上传速度 - 也适用于带有电话线的调制解调器 - 以及所有文件数量。
那么是否存在错误？ - 可能只是某些默认初始配置的问题。进程优先级设置并未解决问题。但问题可能与当前 Ubuntu 高级图形功能的计算优先级有关（我学会了喜欢它们......）。
也许这个 FTP 问题并不重要。在将这个问题发布到这个网站上之前，我通过 Google 查找过，没有发现其他人遇到过同样的问题。
其他可能的原因？
其他完全不同的原因可能是：由于当前的本地变化导致互联网连接不稳定，
并且 UBUNTU 配置（自 2011 年底起）的漏洞比 Fedora Core（自 2009 起）的漏洞更高。
所以让我们忘掉它吧……