On 6 Nov 2013, at 1:17, [email protected] wrote:

> Hello,
> 
> I've been using mediaproxy for years without issues, but recently
> encountered a problem when upgrading kernel version on Debian.
> 
> In recent Debian versions, /proc/sys/kernel/osrelease
> (KERNEL_VERSION_FILE in media-relay) looks for example this way:
> 
>    $ cat /proc/sys/kernel/osrelease 
>    3.10-3-amd64

This is how it was forever. I have older machines with 2.6.x and they show up 
the same:

$ cat /proc/sys/kernel/osrelease
2.6.32-3-686

> which doesn't match the format expected by the script (and causes
> media-relay to fail at startup).

Actually this is the format the script expected since I remember it. Mediaproxy 
detects the kernel version fine both on older and newer debian systems as I do 
not see any difference in the format.

> 
> It seems odd that we would rely on the various distributions to gather
> the kernel version, when we could use /proc/sys/kernel/version
> 
>    $ cat /proc/sys/kernel/version 
>    #1 SMP Debian 3.10.11-1 (2013-09-10)

Unfortunately that is not the kernel version and the fact that in your case the 
kernel version is tucked in there is a matter of coincidence. I have 2 
machines, one with 2.6.x and one with 3.x that don't have it in there (both 
Debian BTW, so it seems that it is not present in there even if you use the 
same distribution):

machine1:~$ cat /proc/sys/kernel/osrelease
2.6.32-3-686
machine1:~$ cat /proc/sys/kernel/version
#1 SMP Thu Feb 25 06:14:20 UTC 2010

machine2:~$ cat /proc/sys/kernel/osrelease
3.2.0-0.bpo.2-686-pae
machine2:~$ cat /proc/sys/kernel/version
#1 SMP Sun Jun 3 22:21:19 UTC 2012

Also, while something resembling the kernel version seems to be there, it 
doesn't match the actual kernel version (this is from another Debian system):

machine3:~$ cat /proc/sys/kernel/osrelease
3.10-3-686-pae
machine3:~$ cat /proc/sys/kernel/version
#1 SMP Debian 3.10.11-1 (2013-09-10)
machine3:~$ uname -r
3.10-3-686-pae

As you can see, the file has 3.10.11-1 tucked in there, but the actual kernel 
version is 3.10-3 (as reported by both the osrelease file and uname -r). 

So we can conclude that /proc/sys/kernel/version is pretty much useless in 
determining the kernel version.

> which I assume contains the proper value

Not even (see the last example above).

> (although maybe in a
> not-so-stable format).
> 
> I'm proposing the changes described here
>  https://gist.github.com/shimaore/7328080
> (which first try to use the current method, then fallback to using
> kernel/version) for consideration & integration by AG Projects.

By looking at your patch, I believe I have an idea why it doesn't work for you. 
Are you using stock mediaproxy version 2.5.2? Because your patch suggests 
otherwise. This change, proposed by the patch:

     try:
-        major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split(" ", 1)[3].split(".")[:3]]
+        major, minor, revision = [int(num) for num in 
open(OS_RELEASE_FILE).read().split("-", 1)[0].split(".")[:3]]
     except:

indicates that you try to replace this line from the original version:

major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split(" ", 1)[3].split(".")[:3]]

however that line is not present in that form in stock mediaproxy-2.5.2. The 
actual line in our version is:

major, minor, revision = [int(num) for num in 
open(KERNEL_VERSION_FILE).read().split("-", 1)[0].split(".")[:3]]

which is exactly what you try to change it to.

So if the source you try to change looks like in your patch, there is no wonder 
it doesn't work as that form cannot parse the output from osrelease.

So I suggest you try out stock mediaproxy 2.5.2 without any alterations or use 
the latest version from the darcs repository and see if the problem persists. 
If it does, please post the output from the osrelease file and the backtrace so 
we can take a look at what's different. Currently I'm running the latest kernel 
from debian unstable and nothing has changed in the format of that file.

--
Dan





_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to