Get OS uptime
Locked
 
|
Hi everyone,
I can't find out how to get the uptime of the OS from pharo. I tried: (FileLocator root / 'proc' / 'uptime') readStream contents. and (FileSystem disk root / 'proc' / 'uptime') readStream contents. but all what I get is an empty string ''. I don't know if there are messages in some specific classes to do this (in OSProcess for example?). Thanks in advance. Julien |
|
'/proc/uptime' asFileReference readStreamDo: [ :stream | stream contents ].
is better way. but you will still get an empty string because actually ‘/proc’ does not contains real files… so the file plugin does not applies there (and is another debate if it should…) you should use OSProcess instead (installable from Configurations Browser) (PipeableOSProcess command: 'uptime') upToEndOfFile. Esteban > On 19 Mar 2015, at 07:07, Julien Delplanque <[hidden email]> wrote: > > Hi everyone, > > I can't find out how to get the uptime of the OS from pharo. > > I tried: > > (FileLocator root / 'proc' / 'uptime') readStream contents. > > and > > (FileSystem disk root / 'proc' / 'uptime') readStream contents. > > but all what I get is an empty string ''. > > I don't know if there are messages in some specific classes to do this > (in OSProcess for example?). > > Thanks in advance. > > Julien > |
|
|
On 19/03/15 11:10, Esteban Lorenzano wrote: > '/proc/uptime' asFileReference readStreamDo: [ :stream | stream contents ]. > > is better way. > > but you will still get an empty string because actually ‘/proc’ does not contains real files… so the file plugin does not applies there (and is another debate if it should…) > > you should use OSProcess instead (installable from Configurations Browser) > > (PipeableOSProcess command: 'uptime') upToEndOfFile. > > Esteban were files in this directory since you do 'cat /proc/uptime' in a shell. |
|
|
> On 19 Mar 2015, at 11:35, Julien Delplanque <[hidden email]> wrote: > > > On 19/03/15 11:10, Esteban Lorenzano wrote: >> '/proc/uptime' asFileReference readStreamDo: [ :stream | stream contents ]. >> >> is better way. >> >> but you will still get an empty string because actually ‘/proc’ does not contains real files… so the file plugin does not applies there (and is another debate if it should…) >> >> you should use OSProcess instead (installable from Configurations Browser) >> >> (PipeableOSProcess command: 'uptime') upToEndOfFile. >> >> Esteban > Oh, I didn't know '/proc' doesn't contains real files. I tought there > were files in this directory since you do 'cat /proc/uptime' in a shell. that’s the O.S. cheating you :) Esteban |
|
|
On 19/03/15 11:51, Esteban Lorenzano wrote: >> On 19 Mar 2015, at 11:35, Julien Delplanque <[hidden email]> wrote: >> >> >> On 19/03/15 11:10, Esteban Lorenzano wrote: >>> '/proc/uptime' asFileReference readStreamDo: [ :stream | stream contents ]. >>> >>> is better way. >>> >>> but you will still get an empty string because actually ‘/proc’ does not contains real files… so the file plugin does not applies there (and is another debate if it should…) >>> >>> you should use OSProcess instead (installable from Configurations Browser) >>> >>> (PipeableOSProcess command: 'uptime') upToEndOfFile. >>> >>> Esteban >> Oh, I didn't know '/proc' doesn't contains real files. I tought there >> were files in this directory since you do 'cat /proc/uptime' in a shell. > that’s the O.S. cheating you :) > > Esteban > Julien |
|
|
In reply to this post by EstebanLM
> Am 19.03.2015 um 11:51 schrieb Esteban Lorenzano <[hidden email]>: > > >> On 19 Mar 2015, at 11:35, Julien Delplanque <[hidden email]> wrote: >> >> >> On 19/03/15 11:10, Esteban Lorenzano wrote: >>> '/proc/uptime' asFileReference readStreamDo: [ :stream | stream contents ]. >>> >>> is better way. >>> >>> but you will still get an empty string because actually ‘/proc’ does not contains real files… so the file plugin does not applies there (and is another debate if it should…) >>> >>> you should use OSProcess instead (installable from Configurations Browser) >>> >>> (PipeableOSProcess command: 'uptime') upToEndOfFile. >>> >>> Esteban >> Oh, I didn't know '/proc' doesn't contains real files. I tought there >> were files in this directory since you do 'cat /proc/uptime' in a shell. > > that’s the O.S. cheating you :) > Norbert |
|
|
"proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information centre for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory.” last part of that sentence is what made me think that *maybe* FilePlugin should thread them as regular files… :) Esteban
|
|
|
In reply to this post by NorbertHartl
/proc are entries in the filesystem, as such I don't see why the file plugin would fail to access them… unless you cannot use block devices and such like any other file? In Unix, everything is a file, except those that have to be special-cased apart? On 19 March 2015 at 13:08, Norbert Hartl <[hidden email]> wrote:
|
|
|
In reply to this post by EstebanLM
s/thread/treat
|
|
|
In reply to this post by EstebanLM
That's my point. Or better I like to know how the plugin can distinguish them. Usually there shouldn't be a difference. I know the /proc filesystem. It is what unix is all about. Make every information available as file. You say it is a virtual filesystem? Yes, but there are only virtual filesystems in linux. Below is always a device driver accessing disks, cdroms, etc. Memory or the kernel does not make a difference. They are all the same and they should according to unix. So I still not understand the problem. Norbert |
|
|
Excerpts from Norbert Hartl's message of 2015-03-19 14:09:28 +0100:
> That's my point. Or better I like to know how the plugin can distinguish > them. Usually there shouldn't be a difference. I know the /proc filesystem. > It is what unix is all about. Make every information available as file. You > say it is a virtual filesystem? Yes, but there are only virtual filesystems > in linux. Below is always a device driver accessing disks, cdroms, etc. > Memory or the kernel does not make a difference. They are all the same and > they should according to unix. So I still not understand the problem. files in /proc are not seekable. that or something related may be the problem. compare this strace: /proc/uptime: lstat64("/proc/uptime", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 open("/proc/uptime", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff722e000 fstat64(8, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 close(8) = 0 /etc/profile: lstat64("/etc/profile", {st_mode=S_IFREG|0644, st_size=1750, ...}) = 0 open("/etc/profile", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=1750, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff722e000 fstat64(8, {st_mode=S_IFREG|0644, st_size=1750, ...}) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 read(8, "# /etc/profile\n\n# System wide en"..., 1750) = 1750 _llseek(8, 1750, [1750], SEEK_SET) = 0 _llseek(8, 1750, [1750], SEEK_SET) = 0 read(8, "", 4096) = 0 _llseek(8, 0, [0], SEEK_SET) = 0 close(8) = 0 /proc/uptime comes with a filesize of 0, and this, pharo tries to read 0 bytes from it. or rather, since there is no read() call, it concludes that there is nothing to read. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
In reply to this post by Julien Delplanque
Hi,
your solution does not work because files in /proc are virtual and have no size (their size will be reported as 0). FileStream>>contents sends #size to determine the length and that will return 0 for all files in /proc. So the solution is to use something that does not use #size, like: (FileLocator root / 'proc' / 'uptime') readStream upToEnd Michal On 19.3.2015 07:07, Julien Delplanque wrote: > Hi everyone, > > I can't find out how to get the uptime of the OS from pharo. > > I tried: > > (FileLocator root / 'proc' / 'uptime') readStream contents. > > and > > (FileSystem disk root / 'proc' / 'uptime') readStream contents. > > but all what I get is an empty string ''. > > I don't know if there are messages in some specific classes to do this > (in OSProcess for example?). > > Thanks in advance. > > Julien > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |