[OpenSIPS-Users] mediaproxy-relay: kernel version problem

[Dan Pascu]

On 6 Nov 2013, at 1:17, stephane at shimaore.net 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