迅雷论坛 -
Powered by Discuz! Archiver
高速通道进入失败，云端建立任务失败，已经好几天了
高速通道进入失败，云端建立任务失败，已经好几天了
在2台电脑上试过，都不行，没有装任何防火墙，360和QQ管家都没装
1、 如是个别资源高速通道进入失败；
这个可能是资源上存在异常问题，建议您使用离线下载加速，离线云端能100%完成都可以正常加速下载的或更换资源连接下载。
2、 如是全部资源高速通道进入失败；
3.1 核实问题是否突然出现的，突然出现的情况，优先建议重新连接网络尝试。
（1）建议重新启动迅雷，并且把占带宽大的程序暂时关闭，例如关闭在线缓冲电影的网页或播放和暂停下载。
（2）重新启动电脑和连接网络尝试。
3.2 出现好几天的情况，可跳过3.1排除。
如果不是独享的网络（例：一条网线一个人自己使用，不是通过路由器分的网络），例如校园网，公司网络，小区网络，可咨询身边的同学或者朋友是否可以正常使用，如果身边的同事和朋友都无法正常使用，您当前的网络肯定存在对迅雷的限制或者异常，建议您咨询内部网管和提供网络的运营商是否对迅雷做出限制。
详细解决方法请进入：/problemVer.html?serialnum=1018&contentFno=0001
查看完整版本:为什么我的离线下载总是迅雷云端任务建立失败_百度知道
为什么我的离线下载总是迅雷云端任务建立失败
要和我说什么离线下载不是万能的，只不过下载很慢，我读书少，但是花了钱的离线下载却不能，不是离线都能下载，但是也别拿这种弱智答案来敷衍我
提问者采纳
已回答280654
响应时间&17小时
其他类似问题
迅雷的相关知识
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁CoreOS实践指南（三）：系统服务管家Systemd
发表于 11:23|
摘要：CoreOS是采用了高度精简的系统内核及外围定制的操作系统。ThoughtWorks的软件工程师林帆将带来“漫步云端：CoreOS实践指南”系列文章，介绍CoreOS精华和推荐的实践方法。本文为基础第三篇：系统服务管家Systemd。
【编者按】作为一个操作系统，CoreOS 采用了高度精简的系统内核及外围定制，将许多原本需要复杂人工操作或者第三方软件支持的功能在操作系统级别进行了实现，同时剔除了其他对于服务器系统非核心的软件，比如GUI和包管理器。来自ThoughtWorks的软件工程师林帆将带来“漫步云端：CoreOS实践指南”系列文章，带大家了解CoreOS的精华和推荐的实践方法。本文为基础第三篇：系统服务管家Systemd。作者简介：林帆，生在80后尾巴的IT攻城狮，ThoughtWorks成都办公室CloudOps小组成员，平时喜欢在业余时间研究DevOps相关的应用，目前在备考AWS认证和推广Docker相关技术。
在系列教程的第一篇里我们已经提到了Systemd，它主要的设计目标是克服传统Linux主流启动程序SysVinit 固有的缺点，提高系统的启动速度。相比同类的
SysVinit 竞争者，例如Ubuntu 的 upstart，Systemd 的设计更加前卫，简单来说，它的设计思路借鉴了Mac系统的启动程序Launchd。事实上Systemd的作用远不仅是启动系统，它还接管了系统服务的启动、结束、状态查询和日志归档等职责，并支持定时任务和通过特定事件（如插入特定USB设备）和特定端口数据触发的任务。在CoreOS的世界里，推荐的做法是使用Systemd来管理所有用户服务，包括运行在应用容器（如Docker）中的服务。
值得指出的是，Systemd并不是CoreOS特有的服务。本质上说Systemd是没有依附于任何一个Linux发行版的独立项目，由于Systemd的作者Lennart
Poettering 就职于红帽，整个项目实际由RedHat公司主导。虽然RedHat Linux直到2014年中旬才用上Systemd，但RedHat旗下的Fedora早在2011年时就已经引进了Systemd作为其启动管理程序了。
在开始使用Systemd之前，先了解一下Systemd有哪些特别之处。
Systemd 的设计理念
尽可能启动更少进程
当SysVinit 程序初始化系统的时，会将所有可能用到的后台服务进程全部运行起来。然而用户需要等待系统将所有服务都启动完成之后，才能够登录。这种做法会带来两个问题：系统的启动时间过长和系统资源的浪费。
Systemd 提供了服务按需启动的能力，使得特定的服务只有在被真正请求的时候才启动。特别是具体硬件相关的服务，比如蓝牙服务仅在蓝牙适配器被插入时才需要运行，打印服务仅在打印机连接或程序要打印时才需要运行，甚至sshd服务也只需要在用户使用ssh连接到服务器时才需要启动。这种能力是建立在对Systemd对DBus总线或特定Socket端口监听的特性上的，这种设计相比于传统启动程序具有颠覆性的进步。&尽可能将更多进程并行启动在SysVinit的时代，将每个服务项目编号的方式依次执行启动脚本。后来Ubuntu的Upstart解决了没有直接依赖的启动项之间的并行启动。而Systemd通过Socket缓存、DBus缓存和建立临时挂载点等方法进一步解决了启动进程之间的依赖，做到了所有系统服务并发启动，这一设计同样是Systemd独具特色的创意。当然，对于用户自定义的服务，Systemd允许配置其启动依赖项目，从而确保服务按必要的顺序运行，稍后会详细描述具体的使用方法。&Systemd启动模型与其它启动模型的对比采用 Cgroup 跟踪和管理进程的生命周期Cgroup的全称是controller group，是将任意进程进行分组化管理的Linux内核功能，最初由Google的工程师提出，从Linux内核版本2.6.24正式启用。拿Android来说，它的应用程序隔离就是使用的这种技术。而很长一段时间里，在更广阔的服务器领域，一直并没有一种主流的服务管理程序能够充分利用这种早已在手机端带来广泛好处的特性。而Systemd正是Cgroup方面的行家，它的出现正好弥补了这个领域的缺漏。通过Cgroup，Systemd不仅实现了服务之间的访问隔离，还能够限制特定应用程序对系统资源访问配额（比如CPU的用量、内存的量），以及精确的管理服务的生命周期。在这篇文章的后面部分会讲述相关操作具体的做法。统一管理服务日志使用Systemd 必须知道的还有它的伙伴：Journald日志服务，这个服务的设计初衷是克服现有syslog服务的日志内容易伪造和日志格式不统一等缺点，而它现在已经是Systemd的一个标准子服务了。Journald用二进制格式保存所有日志信息，用户需要使用&journalctl 命令来查看日志信息。在这篇文章的后面会介绍如何查看服务的日志。&第一个Hello World服务Unit和Target先介绍两个概念，Unit和Target。Unit是Systemd管理服务的基本单元，可以认为每个服务就是一个Unit，并使用一个Unit文件定义。Unit文件中需要包含相应服务的描述、属性以及需要运行的命令。在CoreOS中服务运行的命令通常是一系列的容器操作，而将具体的服务进程封装在容器中。Target是Systemd中用于指定服务启动组的方式（相当于SysVinit中的“运行级别”，如果不清楚这个概念也没有关系，搜索“Linux运行级别”可以查到很多相关文章）。每次系统启动的时候都会运行与当前系统相同级别Target关联的所有服务，如果服务不需要跟随系统自动启动，则完全可以忽略这个Target的内容。通常来说我们大多数的Linux用户平时使用的都是“多用户模式”这个级别，对应的Target值为“multi-user.target”。Hello World服务的Unit文件只说不做假把式，现在我们来用Systemd创建一个简单的系统服务。在这个系列的上一节内容里，我们创建了一个由3个CoreOS虚拟机节点组成的集群，在这节中，我们只需要使用到其中的任意一个，比如coreo-01节点。首先使用ssh连接进入这个节点（这种方法适用于Linux/Mac用户，对于Windows用户需使用Putty客户端，&）。vagrant ssh core-01登录成功后提示符变成 “core@core-01 ~ $” ，祝贺你又向CoreOS迈出了重要一步，接下来就可以开始在CoreOS里面玩耍了。Systemd约定，服务的Unit文件需放置在 /etc/systemd/system 或 &/usr/lib/systemd/system 目录中，但由于在CoreOS的后一个目录是只读分区（整个/usr目录挂载的都是只读的系统分区），因此我们通常会将用户定义的Unit服务文件放在在/etc/systemd/system目录中。进入这个目录，新建一个叫“hello.service”的文件，内容入下。[Unit]&Description=Hello World&After=docker.service&Requires=docker.service&[Service]&TimeoutStartSec=0&ExecStartPre=-/usr/bin/docker kill busybox1&ExecStartPre=-/usr/bin/docker rm busybox1&ExecStartPre=/usr/bin/docker pull busybox&ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c " do echo Hello W sleep 1; done"&ExecStop=”/usr/bin/docker kill busybox1”&[Install]&WantedBy=multi-user.target在这个Unit文件里，我们首先为这个服务提供了一行简短的描述，然后指明它需要依赖docker的服务，并且要在docker服务运行以后才能运行。整个Unit文件是用的ini文件风格的分组配置格式，最开始的这段配置被放在了Unit组里面。在接下来的Service组中，使用ExecStart和ExecStop属性分别指定了服务运行时和结束时需要执行的命令。最后在Install组的配置中，我们指定了服务所属的Target为multi-user.target。这里需要注意两个地方，首先ExecStart属性只能包含一条主要命令，而在这个属性的前后可以分别使用ExecStartPre和ExecStartPost指定更多的辅助命令，ExecStop同理。有些辅助命令会加上一个减号，表示忽略这些命令的出错（因为有些“辅助”命令本来就不一定成功，比如尝试清空一个文件，但文件可能不存在）。其次TimeoutStartSec=0这行的目的是将Systemd的服务启动超时检查关闭，对于docker应用这样做是必须的，因为docker在运行时可能会需要下载或更新镜像文件，使得服务启动时间变得很长，这样可以防止Systemd认为服务启动失败而将进程误杀。&启动服务有了Unit文件，现在就可以启动Hello World服务了，在控制台输入以下命令：sudo systemctl start hello.serviceTip：这个名字末尾的 .service 后缀是可以省略的，因为systemctl默认的后缀就是 .service。关于Unit文件后缀的含义，会在后续进阶篇的文章里详细说明。Systemd会自动找到&/usr/lib/systemd/system 目录中的 hello.service 文件，并启动其中定义的服务。如果之前创建的Unit文件是放在其他目录下的，这里需要使用文件的完整路径。首次运行的时候需要等待一段时间，因为docker需要从网络上下载需要的镜像。启动完成后可以通过“systemctl list-units”命令查看服务是否已经在运行（这个命令接受一个可选参数作为服务名的过滤条件，如果不带任何参数则输出所有服务）。core@core-01 ~ $ sudo systemctl list-units hello*&UNIT& LOAD& ACTIVE& SUB& DESCRIPTION&hello.service& loaded& active& running& Hello World我们还可以通过“systemctl enable”命令来将服务指定为在系统启动时自动启动。sudo systemctl enable hello.service此时就用到了之前定义的Target组，实际上enable操作只是创建了一个连接文件到指定的Target组的目录下面。通过下面命令可以证实。core@core-01 ~ $ ls -l /etc/systemd/system/multi-user.target.wants/hello.service&/etc/systemd/system/multi-user.target.wants/hello.service -& /etc/systemd/system/hello.service系统启动时，会自动运行其所在Target级别相应的目录里所有链接的服务。&日志管理至此，我们的第一个服务已经在后台哈皮的玩耍了，可是说好的“echo Hello World”呢？我们从头到尾都没有见到服务的任何输出啊。其实我们启动的服务已经在后台默默的输出“Hello World”了。Systemd通过其标准日志服务Journald将其管理的所有后台进程打印到到std:out（即控制台）的输出重定向到了日志文件。日志文件是二进制格式的，因此必须使用特定的工具才能查看。Journald提供了配套的程序Journalctl用于处理日志内容。Journalctl的使用非常简单，默认不带任何参数的时候会输出系统和所有后台进程的混合日志，常用的参数有--dmesg用于查看内核输出的日志，--system用于查看系统输出的日志，--unit加上Unit的名字来指定输出特定Unit的日志，例如以下命令。journalctl --unit hello.service其他还有一些比较实用的参数，比如使用 --follow 实时跟踪日志输出，使用 --since 和 --until 指定显示的日志时间区间等，可以通过 journalctl --help 命令获得完整的参数说明。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章云端建立任务失败是什么意思？_百度知道
云端建立任务失败是什么意思？
我用的是校园网我是迅雷会员，但是重装电脑后一个东西都下不了，不知道这是为什么，然后我输入CMD测试是请求超时，但是我网可以上
我有更好的答案
按默认排序
您好，欢迎您向迅雷网络平台提问尊敬的迅雷用户，您可以百度搜索封杀查看工具测试网络是否被封杀更多疑问：您所在的网络运营应该做对应封杀
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁注册Bmob帐号
在网址栏输入或者在百度输入Bmob进行搜索，打开Bmob官网后，点击右上角的“注册”，在跳转页面填入你的姓名、邮箱、设置密码，确认后到你的邮箱激活Bmob账户，你就可以用Bmob轻松开发应用了。
网站后台创建应用
登录账号进入bmob后台后，点击后台界面左上角“创建应用”，在弹出框输入你应用的名称，然后确认，你就拥有了一个等待开发的应用。
获取应用密钥和下载SDK
选择你要开发的应用，点击该应用下方对应的“应用密钥”
在跳转页面，获取Application ID，此ID将会在初始化SDK中使用到。
获取Application ID后，下载SDK，开发者可以根据自己的需求选择相应的iOS SDK 或Android SDK，点击下载即可。
创建云端代码
在Bmob后台中，选择你刚刚创建好的应用，然后依次点击“云端代码-&添加”，在弹出窗口中输入云端代码的方法名，该方法名将会在SDK调用时使用到。如下图所示：
接着，你就可以在云端代码的编辑器中撰写云端代码了。如果你熟悉js脚本语言的话，撰写云端代码非常简单，你只需要在onRequest方法中补充你的业务逻辑代码就可以了。onRequest方法包含3个参数，分别是request（请求对象，可以从中获取SDK上传的参数）, response（回应对象，可以将云端代码的执行结果返回到SDK中）, modules（可调用的模块，包含数据库对象、HTTP对象等）。为方便演示，这里简单实现一个功能：接收客户端上传上来的name参数，根据name的值返回不同的结果。代码如下：
function onRequest(request, response, modules) {
//获取SDK客户端上传的name参数
var name = request.body.
if(name == 'bmob')
response.end('欢迎使用Bmob');
response.end('输入错误，请重新输入');
安装和初始化BmobSDK
云端代码的调用执行可以是在云端（通过“定时任务”模块去设置执行，实现定时业务逻辑计算的功能，如排行榜，这个操作非常简单，这里不再一一介绍），但更多的开发者是通过SDK调用的方式来执行云端代码。这有点像存储过程，大家可以将更多的业务逻辑放在云端，可以随意改变，不需要更新应用，也不需要上传太多的数据参数。
安装和初始化SDK的过程大家根据各自的平台（ / 等）具体参考快速入门文档即可。
调用云端代码
将如下的代码根据各自平台，插入到触发执行的方法里面。
Android调用云端代码
//test对应你刚刚创建的云端代码名称
String cloudCodeName = &test&;
JSONObject params = new JSONObject();
//name是上传到云端的参数名称，值是bmob，云端代码可以通过调用request.body.name获取这个值
params.put(&name&, &bmob&);
//创建云端代码对象
AsyncCustomEndpoints cloudCode = new AsyncCustomEndpoints();
//异步调用云端代码
cloudCode.callEndpoint(MainActivity.this, cloudCodeName, params, new CloudCodeListener() {
//执行成功时调用，返回result对象
public void onSuccess(Object result) {
Log.i(&bmob&, &result = &+result.toString());
//执行失败时调用
public void onFailure(String err) {
Log.i(&bmob&, &BmobException = &+err);
iOS调用云端代码
//name是上传到云端的参数名称，值是bmob，云端代码可以通过调用request.body.name获取这个值
NSDictionary
*dic = [NSDictionary
dictionaryWithObject:@&bmob& forKey:@&name&];
//test对应你刚刚创建的云端代码名称
[BmobCloud callFunctionInBackground:@&test& withParameters:dic block:^(id object, NSError *error) {
if (!error) {
//执行成功时调用
NSLog(@&error %@&,[object description]);
//执行失败时调用
NSLog(@&error %@&,[error description]);