当前位置: 操作系统/服务器>linux
本页文章导读:
▪w3wp进程发生死锁ISAPI aspnet_isapi.dll报告它自身有问题,原因Deadlock detected
这个问题,字面意思是程序发生死锁了,它会导致w3wp进程重启。通常这个问题不好查到原因。我知道两个可能导致此问题的实例 1. 在程序中使用了lock或者ReaderWriterLock,锁资源发生了争用 .........
▪nginx 关闭默认站点的方法
当别人把垃圾域名转向至你的服务器时, 如果不采取措施,那么后果不堪设想。 国内机房一般都要求网站主关闭空主机头,防止未备案的域名指向过来造成麻烦。 Nginx默认的虚拟主机允许.........
▪KLOXO重置管理员登陆密码的方法分享
在使用 Kloxo 的过程当中,有可能因为某些原因而遗失 Kloxo 的默认管理员(admin)密码。如果不幸遗失 Kloxo 的默认管理员密码,那么就没有办法进入 Kloxo 管理面板了。Kloxo 开发团队在设计时.........
[1]w3wp进程发生死锁ISAPI aspnet_isapi.dll报告它自身有问题,原因Deadlock detected
来源: 互联网 发布时间: 2013-12-24
这个问题,字面意思是程序发生死锁了,它会导致w3wp进程重启。通常这个问题不好查到原因。我知道两个可能导致此问题的实例
1. 在程序中使用了lock或者ReaderWriterLock,锁资源发生了争用
下面是一小段代码:
//_rwLock的类型是ReaderWriterLock
_rwLock.AcquireWriterLock(100);
DoSomething();
_rwLock.ReleaseWriterLock();
这行代码是有问题的,如果在DoSomething()方法执行中发生一次异常,这个写锁就释放不了了,再次请求时就会等待直到超时,在多线程的情况下就会发生死锁'Deadlock detected'
正确的写法应该是:
try
{
_rwLock.AcquireWriterLock(100);
DoSomething();
}
finally
{
if (_rwLock.IsWriterLockHeld)
_rwLock.ReleaseWriterLock();
}
这样就算在DoSomething方法执行时发生了异常,也可以释放写锁。
2. 数据库连接的超时时间设置的很长而在设定的超时时间之内连接耗尽了,再次要求打开数据库连接时也可能会出现此问题。这个是数据库连接串的配置问题,超时时间要设置的适当,不要过长。
发生这个问题时的日志写的很笼统:
ISAPI 'c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll' 报告它自身有问题,原因如下: 'Deadlock detected'。
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
这样导致不容易找到问题发生在哪块,所以我记录两种发生此问题的实例,希望有用。
问题分析方法(这个很有必要的)
今天系统突然折了,但是问题在哪呢?很费周折。
错误信息:
ISAPI'c:windowsmicrosoft.netframeworkv2.0.50727aspnet_isapi.dll'报告它自身有问题,原因如下:'检测到死锁'。
有关更多信息,请参阅在http://go.microsoft.com/fwlink/events.asp的帮助和支持中心。
症状:系统总是不稳定,一会能用,一会儿又死掉了。
分析过程:
这个版本已经跑了很长时间,估计不是程序死锁的问题。倒底是什么问题呢。应该是外部环境的问题。由于错误信息比较的抽象,之前没有遇到过,所以google了下,但是好像遇到此问题的人很少,不过在博客园还是遇到一位受到同样遭遇的人,但是并没有一种很好的解决方案,也没有确切的指出问题的症结。所以只有自己进行一些检查。
<1>查看最近的系统更新,看是否有关于IIS之类的更新
<2>查看系统的杀毒软件的日志文件,看是否收到了攻击
但是,检查上述两个步骤,并没有发现问题。看系统是有一些更新,迫于无奈,只好重启系统试一下(也顺便重启IIS)。重启之后,问题依旧。
观察进程管理器,发现:
W3WP的线程数,一直在变化,一会增加一个高峰值,重新增加一个W3WP进程,之前的进程过一会就自动关闭,一会又恢复正常。
这说明网站,在不断的死亡、重启。到底是哪里的问题呢?应该还是系统自己的问题了。但是它自身的版本并没有问题,为了确定这一点,我也试了之前稳定的版本,同样出现此类问题。最后,是否是系统中调用的第三方服务,将整个系统给拖死了呢?
罪魁祸首:经过检查,果然是由于程序中实时调用了一个服务,由于此服务已经停止,请求无果,出现了死锁。
教训:
<1>最大大限度保证系统与第三方服务的稳定、安全,并在请求过程中做超时判断、消息分级处理。
<2>遇到问题,首先应全面分析系统的问题可能性,因为系统本身的运行环境一般都是固定不变的,出现问题的可能性很小。
有的时候在写程序的时候,如果出了问题,首先应该怀疑自己的思路、代码哪里出了问题,而不应该去怪罪IDE或者OS出了什么BUG。这样你就少走很多弯路。
通过上边的介绍,我出现此问题的原因是:(在此贴出备注一下)
首选我代码里没有用到加锁代码(例如:Application.Lock(), Application.UnLock()等);
其次在此问题之前,没有出现过此问题,并且良好运行过很长时间;
最后发现,由于我代码里调用c/c++ DLL, 而DLL里要链接网关服务,然后网关服务此时没有开启,从而出错,开启DLL需要的网关服务,就可以了。
1. 在程序中使用了lock或者ReaderWriterLock,锁资源发生了争用
下面是一小段代码:
代码如下:
//_rwLock的类型是ReaderWriterLock
_rwLock.AcquireWriterLock(100);
DoSomething();
_rwLock.ReleaseWriterLock();
这行代码是有问题的,如果在DoSomething()方法执行中发生一次异常,这个写锁就释放不了了,再次请求时就会等待直到超时,在多线程的情况下就会发生死锁'Deadlock detected'
正确的写法应该是:
代码如下:
try
{
_rwLock.AcquireWriterLock(100);
DoSomething();
}
finally
{
if (_rwLock.IsWriterLockHeld)
_rwLock.ReleaseWriterLock();
}
这样就算在DoSomething方法执行时发生了异常,也可以释放写锁。
2. 数据库连接的超时时间设置的很长而在设定的超时时间之内连接耗尽了,再次要求打开数据库连接时也可能会出现此问题。这个是数据库连接串的配置问题,超时时间要设置的适当,不要过长。
发生这个问题时的日志写的很笼统:
ISAPI 'c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll' 报告它自身有问题,原因如下: 'Deadlock detected'。
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
这样导致不容易找到问题发生在哪块,所以我记录两种发生此问题的实例,希望有用。
问题分析方法(这个很有必要的)
今天系统突然折了,但是问题在哪呢?很费周折。
错误信息:
ISAPI'c:windowsmicrosoft.netframeworkv2.0.50727aspnet_isapi.dll'报告它自身有问题,原因如下:'检测到死锁'。
有关更多信息,请参阅在http://go.microsoft.com/fwlink/events.asp的帮助和支持中心。
症状:系统总是不稳定,一会能用,一会儿又死掉了。
分析过程:
这个版本已经跑了很长时间,估计不是程序死锁的问题。倒底是什么问题呢。应该是外部环境的问题。由于错误信息比较的抽象,之前没有遇到过,所以google了下,但是好像遇到此问题的人很少,不过在博客园还是遇到一位受到同样遭遇的人,但是并没有一种很好的解决方案,也没有确切的指出问题的症结。所以只有自己进行一些检查。
<1>查看最近的系统更新,看是否有关于IIS之类的更新
<2>查看系统的杀毒软件的日志文件,看是否收到了攻击
但是,检查上述两个步骤,并没有发现问题。看系统是有一些更新,迫于无奈,只好重启系统试一下(也顺便重启IIS)。重启之后,问题依旧。
观察进程管理器,发现:
W3WP的线程数,一直在变化,一会增加一个高峰值,重新增加一个W3WP进程,之前的进程过一会就自动关闭,一会又恢复正常。
这说明网站,在不断的死亡、重启。到底是哪里的问题呢?应该还是系统自己的问题了。但是它自身的版本并没有问题,为了确定这一点,我也试了之前稳定的版本,同样出现此类问题。最后,是否是系统中调用的第三方服务,将整个系统给拖死了呢?
罪魁祸首:经过检查,果然是由于程序中实时调用了一个服务,由于此服务已经停止,请求无果,出现了死锁。
教训:
<1>最大大限度保证系统与第三方服务的稳定、安全,并在请求过程中做超时判断、消息分级处理。
<2>遇到问题,首先应全面分析系统的问题可能性,因为系统本身的运行环境一般都是固定不变的,出现问题的可能性很小。
有的时候在写程序的时候,如果出了问题,首先应该怀疑自己的思路、代码哪里出了问题,而不应该去怪罪IDE或者OS出了什么BUG。这样你就少走很多弯路。
通过上边的介绍,我出现此问题的原因是:(在此贴出备注一下)
首选我代码里没有用到加锁代码(例如:Application.Lock(), Application.UnLock()等);
其次在此问题之前,没有出现过此问题,并且良好运行过很长时间;
最后发现,由于我代码里调用c/c++ DLL, 而DLL里要链接网关服务,然后网关服务此时没有开启,从而出错,开启DLL需要的网关服务,就可以了。
[2]nginx 关闭默认站点的方法
来源: 互联网 发布时间: 2013-12-24
当别人把垃圾域名转向至你的服务器时, 如果不采取措施,那么后果不堪设想。
国内机房一般都要求网站主关闭空主机头,防止未备案的域名指向过来造成麻烦。
Nginx默认的虚拟主机允许用户经过IP访问,或者经过未设置的域名访问(比如有人把他本人的域名指向了你的ip)你的VPS或服务器。
默认情况下,只要将域名解析到VPS的IP上,就可以访问安装lnmp的VPS。
如果想避免这种情况的出现,可以修改nginx.conf ,将默认的虚拟主机修改为如下即可屏蔽未绑定域名访问:
代码如下:
server {
listen 80 default;
return 500;
}
也可以把这些流量收集起来,导进到本人的网站,只需做以下跳转设置就可以:
代码如下:
server {
listen 80 default;
rewrite ^(.*) http:// permanent;
}
以此类推, 禁止通过IP访问,可以写成:
代码如下:
server {
listen 80 default;
server_name _;
return 500;
}
[3]KLOXO重置管理员登陆密码的方法分享
来源: 互联网 发布时间: 2013-12-24
在使用 Kloxo 的过程当中,有可能因为某些原因而遗失 Kloxo 的默认管理员(admin)密码。如果不幸遗失 Kloxo 的默认管理员密码,那么就没有办法进入 Kloxo 管理面板了。Kloxo 开发团队在设计时就已经考虑到这一点,给用户预留了一个方式来,使得他们在遗失默认管理员密码的时候,可以进行重置。
需要注意的是,要重置 Kloxo 管理员密码,必须通过 SSH 登陆到服务器。这要求对 Linux 以及相关命令有一定的了解,并且熟悉如何通过 SSH 连接到服务器。不过也不需要太过担心,请严格按照本教程的操作顺序,依次输入相关命令即可。
解决方法:putty登陆VPS,然后看下面两句命令对应输入
1.通过 SSH 登陆到您的服务器
2.依次运行以下命令:
cd /usr/local/lxlabs/kloxo/httpdocs
lphp.exe ../bin/common/resetpassword.php master
设置完毕之后,我们就可以重新登陆KLOXO面板,用重置的密码()登陆。
需要注意的是,要重置 Kloxo 管理员密码,必须通过 SSH 登陆到服务器。这要求对 Linux 以及相关命令有一定的了解,并且熟悉如何通过 SSH 连接到服务器。不过也不需要太过担心,请严格按照本教程的操作顺序,依次输入相关命令即可。
解决方法:putty登陆VPS,然后看下面两句命令对应输入
1.通过 SSH 登陆到您的服务器
2.依次运行以下命令:
代码如下:
cd /usr/local/lxlabs/kloxo/httpdocs
lphp.exe ../bin/common/resetpassword.php master
设置完毕之后,我们就可以重新登陆KLOXO面板,用重置的密码()登陆。
最新技术文章: