Обсуждение: pgmonitor and Solaris
I believe I have found the cause of the pgmonitor problem on Solaris. pgmonitor assumes you have a working 'ps' status display, which shows user/database/connection, and query type. I have learned from a Great Bridge employee that his Solaris box is not updating the ps display for 7.1beta, and I assume the same trouble exists for 7.0.3. Can someone confirm that 'ps' status display doesn't work on Solaris, and if it doesn't, can someone come up with a fix that we can put into 7.1.1? You can look in /pg/backend/utils/misc/ps_status.c for all the ps status code. It has many options for ps status updating. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian writes: > Can someone confirm that 'ps' status display doesn't work on Solaris, You may need to use /usr/ucb/ps. Last I checked there was no way to change the display of /usr/bin/ps. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Bruce Momjian writes: > > > Can someone confirm that 'ps' status display doesn't work on Solaris, > > You may need to use /usr/ucb/ps. Last I checked there was no way to > change the display of /usr/bin/ps. I can do that, but I am told that /usr/ucb/ps does not allow me to restrict the display to a specific user. Without that, ps shows all processes, which is pretty slow to run regularly, no? Can you check for a user restriction on /usr/ucb/ps. I can certainly code in a check for its existance and use that instead. Does 'ps' status display work with PostgreSQL and /usr/ucb/ps? Let me know. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
whats wrong with /usr/ucb/ps auxw | grep $PGUSER to get only the processes for PG? LER -- Larry Rosenman http://www.lerctr.org/~ler/ Phone: +1 972 414 9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 US >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/28/01, 3:31:08 PM, Bruce Momjian <pgman@candle.pha.pa.us> wrote regarding [HACKERS] Re: [PORTS] pgmonitor and Solaris: > > Bruce Momjian writes: > > > > > Can someone confirm that 'ps' status display doesn't work on Solaris, > > > > You may need to use /usr/ucb/ps. Last I checked there was no way to > > change the display of /usr/bin/ps. > I can do that, but I am told that /usr/ucb/ps does not allow me to > restrict the display to a specific user. Without that, ps shows all > processes, which is pretty slow to run regularly, no? Can you check for > a user restriction on /usr/ucb/ps. I can certainly code in a check for > its existance and use that instead. > Does 'ps' status display work with PostgreSQL and /usr/ucb/ps? > Let me know. Thanks. > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
[ Charset ISO-8859-1 unsupported, converting... ] > whats wrong with /usr/ucb/ps auxw | grep $PGUSER > > to get only the processes for PG? I can do that if there is no other option, but on my BSDI machine, restricting ps to a specific user is much faster than a ps on the whole system. Seeing that 'ps' is run by default every 5 seconds, this could be a performance issue. If I have to use 'grep' I will, but I was hoping for a real user restriction. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, Mar 28, 2001 at 04:56:15PM -0500, Bruce Momjian allegedly wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > whats wrong with /usr/ucb/ps auxw | grep $PGUSER
> >
> > to get only the processes for PG?
>
> I can do that if there is no other option, but on my BSDI machine,
> restricting ps to a specific user is much faster than a ps on the whole
> system. Seeing that 'ps' is run by default every 5 seconds, this could
> be a performance issue.
>
> If I have to use 'grep' I will, but I was hoping for a real user
> restriction.
How about the following:
ilsefe2:~$ /usr/ucb/ps -aux|head -1
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
Broken Pipe
ilsefe2:~$ /usr/ucb/ps -aux|grep mathijs
mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash
mathijs 7775 0.1 0.1 960 728 pts/0 S 00:24:29 0:00 grep mathijs
mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man ps
mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh -c more -s /tmp
mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more -s /tmp/mp3Ha
ilsefe2:~$ ps -U mathijs -o user,pid,pcpu,pmem,vsz,rss,tty,s,stime=START -o time,comm
USER PID %CPU %MEM VSZ RSS TT S START TIME COMMAND
mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh
mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash
root 7816 0.1 0.1 1080 840 pts/0 O 00:28:13 0:00 ps
mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man
mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more
It doesn't use any extra extra programs, nor the somewhat deprecated /usr/ucb/ps
command. The only problem I see may be the alignment of some fields. The ps
command itself is listed because the user mathijs was running it...
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
On Thu, Mar 29, 2001 at 12:30:06AM +0200, Mathijs Brands allegedly wrote:
> On Wed, Mar 28, 2001 at 04:56:15PM -0500, Bruce Momjian allegedly wrote:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > whats wrong with /usr/ucb/ps auxw | grep $PGUSER
> > >
> > > to get only the processes for PG?
> >
> > I can do that if there is no other option, but on my BSDI machine,
> > restricting ps to a specific user is much faster than a ps on the whole
> > system. Seeing that 'ps' is run by default every 5 seconds, this could
> > be a performance issue.
> >
> > If I have to use 'grep' I will, but I was hoping for a real user
> > restriction.
>
> How about the following:
>
> ilsefe2:~$ /usr/ucb/ps -aux|head -1
> USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
> Broken Pipe
> ilsefe2:~$ /usr/ucb/ps -aux|grep mathijs
> mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash
> mathijs 7775 0.1 0.1 960 728 pts/0 S 00:24:29 0:00 grep mathijs
> mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man ps
> mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh -c more -s /tmp
> mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more -s /tmp/mp3Ha
> ilsefe2:~$ ps -U mathijs -o user,pid,pcpu,pmem,vsz,rss,tty,s,stime=START -o time,comm
> USER PID %CPU %MEM VSZ RSS TT S START TIME COMMAND
> mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh
> mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash
> root 7816 0.1 0.1 1080 840 pts/0 O 00:28:13 0:00 ps
> mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man
> mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more
Damn! Small correction:
ps -U mathijs -o user,pid,pcpu,pmem,vsz=SZ -o rss,tty,s,stime=START -o time,comm
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
> How about the following: > > ilsefe2:~$ /usr/ucb/ps -aux|head -1 > USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND > Broken Pipe > ilsefe2:~$ /usr/ucb/ps -aux|grep mathijs > mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash > mathijs 7775 0.1 0.1 960 728 pts/0 S 00:24:29 0:00 grep mathijs > mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man ps > mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh -c more -s /tmp > mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more -s /tmp/mp3Ha > ilsefe2:~$ ps -U mathijs -o user,pid,pcpu,pmem,vsz,rss,tty,s,stime=START -o time,comm > USER PID %CPU %MEM VSZ RSS TT S START TIME COMMAND > mathijs 7359 0.0 0.1 1040 808 pts/0 T 00:14:57 0:00 sh > mathijs 7255 0.1 0.2 2432 1816 pts/0 S 00:12:41 0:00 -bash > root 7816 0.1 0.1 1080 840 pts/0 O 00:28:13 0:00 ps > mathijs 7344 0.0 0.1 1064 912 pts/0 T 00:14:56 0:00 man > mathijs 7360 0.0 0.1 1184 968 pts/0 T 00:14:57 0:00 more > > > It doesn't use any extra extra programs, nor the somewhat deprecated /usr/ucb/ps > command. The only problem I see may be the alignment of some fields. The ps > command itself is listed because the user mathijs was running it... Sure 'ps -U' will work, but it was reported that on Solaris, plain ps can't show the postgres status display, while ucb/ps can. I don't need specific columns. What I need is the postgres status parameters, and if possible, a user restriction to ps for performance reasons. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote:
> Sure 'ps -U' will work, but it was reported that on Solaris, plain ps
> can't show the postgres status display, while ucb/ps can. I don't need
> specific columns. What I need is the postgres status parameters, and if
> possible, a user restriction to ps for performance reasons.
My mistake. Have a look at this snippet from the ps manpage:
| args The command with all its arguments as a string. The
| implementation may truncate this value to the field
| width; it is implementation-dependent whether any
| further truncation occurs. It is unspecified whether
| the string represented is a version of the argument
| list as it was passed to the command when it started,
| or is a version of the arguments as they may have been
| modified by the application. Applications cannot
| depend on being able to modify their argument list and
| having that modification be reflected in the output of
| ps. The Solaris implementation limits the string to
| 80 bytes; the string is the version of the argument
| list as it was passed to the command when it started.
Note the last line...
The following must also seem familiar ;)
| The Hermit Hacker <scrappy@hub.org> writes:
| > On Wed, 29 Apr 1998, Bruce Momjian wrote:
| >> No reason for the exec(). I believe the only advantage is that it gives
| >> us a separate process name in the 'ps' listing. I have looked into
| >> simulating this.
| > Under FreeBSD, there is:
| > setproctitle(3) - set the process title for ps 1
| > This isn't available under Solaris though, last I checked...
|
| Setting the process title from C is messy, but there is a readily
| available reference. The Berkeley sendmail distribution includes code
| to emulate setproctitle on practically every platform. See conf.h and
| conf.c in any recent sendmail release. Warning: it's grotty enough to
| make a strong man weep. Don't read near mealtime ;-)
|
| regards, tom lane
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
> On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote: > > Sure 'ps -U' will work, but it was reported that on Solaris, plain ps > > can't show the postgres status display, while ucb/ps can. I don't need > > specific columns. What I need is the postgres status parameters, and if > > possible, a user restriction to ps for performance reasons. > > My mistake. Have a look at this snippet from the ps manpage: > > | args The command with all its arguments as a string. The > | implementation may truncate this value to the field > | width; it is implementation-dependent whether any > | further truncation occurs. It is unspecified whether > | the string represented is a version of the argument > | list as it was passed to the command when it started, > | or is a version of the arguments as they may have been > | modified by the application. Applications cannot > | depend on being able to modify their argument list and > | having that modification be reflected in the output of > | ps. The Solaris implementation limits the string to > | 80 bytes; the string is the version of the argument > | list as it was passed to the command when it started. > > Note the last line... OK, I need someone on Solaris to test ps and /ucb/ps with regard to user restriction inside ps, and display of PostgreSQL status display. I have uploaded a new pgmonitor 0.33 version that has a show_all configuration parameter. This will show all PostgreSQL-owned processes for use on operating systems that don't have PostgreSQL status display. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote:
>> Sure 'ps -U' will work, but it was reported that on Solaris, plain ps
>> can't show the postgres status display, while ucb/ps can. I don't need
>> specific columns. What I need is the postgres status parameters, and if
>> possible, a user restriction to ps for performance reasons.
Looking at the sendmail code, it seems they use SPT_REUSEARGV (what we
call PS_USE_CLOBBER_ARGV) technique on Solaris. Possibly the problem is
simply that line 65 in src/backend/utils/misc/ps_status.c fails to
cover Solaris as one of the possible options:
#elif defined(__linux__) || defined(_AIX4) || defined(_AIX3) || defined(__sgi) || (defined(sun) && !defined(BSD)) ||
defined(ultrix)|| defined(__ksr__) || defined(__osf__) || defined(__QNX__) || defined(__svr4__) || defined(__svr5__)
#define PS_USE_CLOBBER_ARGV
Can someone check whether adding an appropriate Solaris symbol (which
one?) fixes the problem?
The coding technique embodied in lines 63-67 pretty much sucks anyway,
since this platform-specific knowledge ought to be out in the port.h
files rather than hidden in the guts of the system. I don't want to
touch it right now, but I think we ought to have things like
#define PS_STATUS_TECHNIQUE PS_USE_CLOBBER_ARGV
in the port.h files, rather than these massive #ifdefs.
regards, tom lane
FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms including UnixWare. The UnixWare code will need /dev/kmem permission to change it's stuff, so I don't know whether we want to do this or not, but if people are looking at the ps stuff, please look at this as well. Larry Rosenman -- Larry Rosenman http://www.lerctr.org/~ler/ Phone: +1 972 414 9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 US >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/28/01, 5:23:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote regarding Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris : > > On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote: > >> Sure 'ps -U' will work, but it was reported that on Solaris, plain ps > >> can't show the postgres status display, while ucb/ps can. I don't need > >> specific columns. What I need is the postgres status parameters, and if > >> possible, a user restriction to ps for performance reasons. > Looking at the sendmail code, it seems they use SPT_REUSEARGV (what we > call PS_USE_CLOBBER_ARGV) technique on Solaris. Possibly the problem is > simply that line 65 in src/backend/utils/misc/ps_status.c fails to > cover Solaris as one of the possible options: > #elif defined(__linux__) || defined(_AIX4) || defined(_AIX3) || defined(__sgi) || (defined(sun) && !defined(BSD)) || defined(ultrix) || defined(__ksr__) || defined(__osf__) || defined(__QNX__) || defined(__svr4__) || defined(__svr5__) > #define PS_USE_CLOBBER_ARGV > Can someone check whether adding an appropriate Solaris symbol (which > one?) fixes the problem? > The coding technique embodied in lines 63-67 pretty much sucks anyway, > since this platform-specific knowledge ought to be out in the port.h > files rather than hidden in the guts of the system. I don't want to > touch it right now, but I think we ought to have things like > #define PS_STATUS_TECHNIQUE PS_USE_CLOBBER_ARGV > in the port.h files, rather than these massive #ifdefs. > regards, tom lane
On Wed, Mar 28, 2001 at 06:23:16PM -0500, Tom Lane allegedly wrote:
> > On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote:
> >> Sure 'ps -U' will work, but it was reported that on Solaris, plain ps
> >> can't show the postgres status display, while ucb/ps can. I don't need
> >> specific columns. What I need is the postgres status parameters, and if
> >> possible, a user restriction to ps for performance reasons.
>
> Looking at the sendmail code, it seems they use SPT_REUSEARGV (what we
> call PS_USE_CLOBBER_ARGV) technique on Solaris. Possibly the problem is
> simply that line 65 in src/backend/utils/misc/ps_status.c fails to
> cover Solaris as one of the possible options:
>
> #elif defined(__linux__) || defined(_AIX4) || defined(_AIX3) || defined(__sgi) || (defined(sun) && !defined(BSD)) ||
defined(ultrix)|| defined(__ksr__) || defined(__osf__) || defined(__QNX__) || defined(__svr4__) || defined(__svr5__)
> #define PS_USE_CLOBBER_ARGV
>
> Can someone check whether adding an appropriate Solaris symbol (which
> one?) fixes the problem?
PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked.
ilsedb:~$ uname -a
SunOS ilsedb 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-80
ilsedb:~$ cat test.c
#include <stdio.h>
main()
{
printf("%d\n", __svr4__);
}
ilsedb:~$ gcc -o test test.c
ilsedb:~$ ./test
1
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
Mathijs Brands <mathijs@ilse.nl> writes:
> PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked.
Hm. But 7.1 postgres backends fail to change their ps display?
Does sendmail change its ps display on your machine?
regards, tom lane
I tend to agree, but wanted someone else's opinion. LER >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/28/01, 5:51:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote regarding Re: [ADMIN] Re: [HACKERS] Re: [PORTS] pgmonitor and Solaris : > Larry Rosenman <ler@lerctr.org> writes: > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms > > including UnixWare. The UnixWare code will need /dev/kmem permission to > > change it's stuff, so I don't know whether we want to do this or not, but > > if people are looking at the ps stuff, please look at this as well. > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem. > Especially not just to make ps_status work... > regards, tom lane
Larry Rosenman <ler@lerctr.org> writes:
> FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> including UnixWare. The UnixWare code will need /dev/kmem permission to
> change it's stuff, so I don't know whether we want to do this or not, but
> if people are looking at the ps stuff, please look at this as well.
Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem.
Especially not just to make ps_status work...
regards, tom lane
On Wed, Mar 28, 2001 at 06:48:27PM -0500, Tom Lane allegedly wrote:
> Mathijs Brands <mathijs@ilse.nl> writes:
> > PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked.
>
> Hm. But 7.1 postgres backends fail to change their ps display?
> Does sendmail change its ps display on your machine?
template1=# \set
VERSION = 'PostgreSQL 7.0.3 on sparc-sun-solaris2.7, compiled by gcc 2.95.2'
DBNAME = 'template1'
USER = 'mathijs'
PORT = '5432'
ENCODING = 'SQL_ASCII'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
HISTSIZE = '500'
template1=#
[1]+ Stopped psql template1
jumpstart.l3.ilse.nl:/export/home/mathijs >/usr/ucb/ps auxww|grep post
mathijs 297 0.1 0.2 6120 3352 pts/1 S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1 idle
mathijs 319 0.1 0.1 944 696 pts/3 S 01:59:45 0:00 grep post
mathijs 25810 0.0 0.1 5736 2160 pts/1 S 20:44:34 0:00 /opt/pgsql/bin/./postmaster
template1=# \set
VERSION = 'PostgreSQL 7.1RC1 on sparc-sun-solaris2.8, compiled by GCC 2.95.3'
DBNAME = 'template1'
USER = 'mathijs'
PORT = '5432'
ENCODING = 'SQL_ASCII'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
template1=# ^Z[1] + Stopped (SIGTSTP) psql template1
$ /usr/ucb/ps auxww|grep post
mathijs 8072 0.1 1.4 5552 3352 pts/2 S 01:01:43 0:00 ./postmaster -D /export/home/mathijs/pgtest/data
mathijs 8074 0.1 0.3 976 672 pts/2 S 01:01:55 0:00 grep post
mathijs 8067 0.1 0.8 4912 1984 pts/2 S 01:01:37 0:00 ./postmaster -D /export/home/mathijs/pgtest/data
I guess it doesn't work :( Of course, it's also possible it doesn't
work on Solaris 8, but does on 7. I'll check this and if this is the
case, I'll post it.
Regards,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
* Tom Lane <tgl@sss.pgh.pa.us> [010328 16:07] wrote: > Larry Rosenman <ler@lerctr.org> writes: > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms > > including UnixWare. The UnixWare code will need /dev/kmem permission to > > change it's stuff, so I don't know whether we want to do this or not, but > > if people are looking at the ps stuff, please look at this as well. > > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem. > Especially not just to make ps_status work... Wow... is this all for "pgmonitor"? sorry, just my opinion... If it for pgmonitor then you guys ought to just mark it broken on these platforms, the non-"ps based" solution could have been implemented with all the time wasted trying to get the "ps based" hack working. :( -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
Alfred Perlstein <bright@wintelcom.net> writes:
> If it for pgmonitor then you guys ought to just mark it broken on
> these platforms, the non-"ps based" solution could have been
> implemented with all the time wasted trying to get the "ps based"
> hack working. :(
My thoughts exactly ;-) ... I'm willing to give advice about this,
but not to do any legwork myself.
PS status display does have some utility with or without pgmonitor,
but not enough to do a lot of work for.
regards, tom lane
Mathijs Brands <mathijs@ilse.nl> writes:
> mathijs 297 0.1 0.2 6120 3352 pts/1 S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1
idle
The interesting point about this is that the 7.0.3-on-2.7 installation
*is* managing to change its PS display. So either Solaris 2.8
retrogressed (different predefined symbols maybe?), or we broke the code
since 7.0.3.
Anyway I think the right thing to look at is why the 7.1 install is not
managing to update the display.
regards, tom lane
> > On Wed, Mar 28, 2001 at 05:33:05PM -0500, Bruce Momjian allegedly wrote: > >> Sure 'ps -U' will work, but it was reported that on Solaris, plain ps > >> can't show the postgres status display, while ucb/ps can. I don't need > >> specific columns. What I need is the postgres status parameters, and if > >> possible, a user restriction to ps for performance reasons. > > Looking at the sendmail code, it seems they use SPT_REUSEARGV (what we > call PS_USE_CLOBBER_ARGV) technique on Solaris. Possibly the problem is > simply that line 65 in src/backend/utils/misc/ps_status.c fails to > cover Solaris as one of the possible options: > > #elif defined(__linux__) || defined(_AIX4) || defined(_AIX3) || defined(__sgi) || (defined(sun) && !defined(BSD)) || defined(ultrix)|| defined(__ksr__) || defined(__osf__) || defined(__QNX__) || defined(__svr4__) || defined(__svr5__) > #define PS_USE_CLOBBER_ARGV > > Can someone check whether adding an appropriate Solaris symbol (which > one?) fixes the problem? > > The coding technique embodied in lines 63-67 pretty much sucks anyway, > since this platform-specific knowledge ought to be out in the port.h > files rather than hidden in the guts of the system. I don't want to > touch it right now, but I think we ought to have things like > > #define PS_STATUS_TECHNIQUE PS_USE_CLOBBER_ARGV > > in the port.h files, rather than these massive #ifdefs. Added to TODO: * Move platform-specific ps status display info from ps_status.c to ports -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Mathijs Brands <mathijs@ilse.nl> writes: > > PS_USE_CLOBBER_ARGV -is- used on Solaris. I just checked. > > Hm. But 7.1 postgres backends fail to change their ps display? > Does sendmail change its ps display on your machine? Seems we could easily use the sendmail display to populate the ps display defines/ports. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Larry Rosenman <ler@lerctr.org> writes: > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms > > including UnixWare. The UnixWare code will need /dev/kmem permission to > > change it's stuff, so I don't know whether we want to do this or not, but > > if people are looking at the ps stuff, please look at this as well. > > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem. > Especially not just to make ps_status work... Agreed. If that is what is required, I think you can forget ps status on that platform. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, Mar 28, 2001 at 07:12:39PM -0500, Tom Lane allegedly wrote:
> Mathijs Brands <mathijs@ilse.nl> writes:
> > mathijs 297 0.1 0.2 6120 3352 pts/1 S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1
idle
>
> The interesting point about this is that the 7.0.3-on-2.7 installation
> *is* managing to change its PS display. So either Solaris 2.8
> retrogressed (different predefined symbols maybe?), or we broke the code
> since 7.0.3.
>
> Anyway I think the right thing to look at is why the 7.1 install is not
> managing to update the display.
>
> regards, tom lane
Here's 7.1:
template1=# \set
VERSION = 'PostgreSQL 7.1RC1 on sparc-sun-solaris2.7, compiled by GCC 2.8.1'
DBNAME = 'template1'
USER = 'mathijs'
PORT = '5432'
ENCODING = 'SQL_ASCII'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
template1=# ^Z
[1]+ Stopped ./psql template1
ilsedb:~/pgtest/bin$ /usr/ucb/ps auxww|grep post
mathijs 29830 0.1 0.2 6328 3976 pts/4 S 02:18:16 0:00 ./postmaster -D /export/home/mathijs/pgtest/data
mathijs 29832 0.1 0.1 960 704 pts/4 S 02:18:28 0:00 grep post
mathijs 29823 0.0 0.1 5696 2176 pts/4 S 02:18:03 0:00 ./postmaster -D /export/home/mathijs/pgtest/data
No go...
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
On Wed, Mar 28, 2001 at 04:10:52PM -0800, Alfred Perlstein wrote:
> * Tom Lane <tgl@sss.pgh.pa.us> [010328 16:07] wrote:
> > Larry Rosenman <ler@lerctr.org> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will need /dev/kmem permission to
> > > change it's stuff, so I don't know whether we want to do this or not, but
> > > if people are looking at the ps stuff, please look at this as well.
> >
> > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem.
> > Especially not just to make ps_status work...
>
> Wow... is this all for "pgmonitor"?
>
> sorry, just my opinion...
>
> If it for pgmonitor then you guys ought to just mark it broken on
> these platforms, the non-"ps based" solution could have been
> implemented with all the time wasted trying to get the "ps based"
> hack working. :(
If is still a mind for (IMHO) terrible work with 'ps'... not sure if
it's interesting, but exist cross-platforms library for processes
information loading - the libgtop. Supports:
* All versions of Linux* FreeBSD, NetBSD and OpenBSD* BSD/OS* Digital Unix* Solaris* ..and may be others
Sure, it's in C :-)
Karel
-- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz
Tom Lane previously wrote: > Looking at the sendmail code, it seems they use SPT_REUSEARGV (what > we call PS_USE_CLOBBER_ARGV) technique on Solaris. Possibly the > problem is simply that line 65 in > src/backend/utils/misc/ps_status.c fails to cover Solaris as one of > the possible options: > > #elif defined(__linux__) || defined(_AIX4) || defined(_AIX3) > || defined(__sgi) || (defined(sun) && !defined(BSD)) > || defined(ultrix) || defined(__ksr__) || defined(__osf__) > || defined(__QNX__) || defined(__svr4__) || defined(__svr5__) > #define PS_USE_CLOBBER_ARGV > Can someone check whether adding an appropriate Solaris symbol > (which one?) fixes the problem? Tom Lane writes: > The interesting point about this is that the 7.0.3-on-2.7 > installation *is* managing to change its PS display. So either > Solaris 2.8 retrogressed (different predefined symbols maybe?), or > we broke the code since 7.0.3. > > Anyway I think the right thing to look at is why the 7.1 install is > not managing to update the display. The identifier sun is not set if the compiler is in -Xc mode. It would be safer to use to use __sun which is defined in all compiler modes. The symbols defined in all modes are __sun, __unix, __SUNPRO_C=0x500 (or 400, 420, etc.), __`uname -s`_`uname -r` (e.g. __SunOS_5_8), __sparc (SPARC), __sparcv9 (SPARC with -xarch=v9|v9a), __i386 (x86), __BUILTIN_VA_ARG_INCR, __SVR4. That applies to the native compiler. Perhaps someone else could establish what Solaris specific defines are available in gcc. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Bruce Momjian wrote:
> > Larry Rosenman <ler@lerctr.org> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will need /dev/kmem permission to
> > > change it's stuff, so I don't know whether we want to do this or not, but
> > > if people are looking at the ps stuff, please look at this as well.
> >
> > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem.
> > Especially not just to make ps_status work...
>
> Agreed. If that is what is required, I think you can forget ps status
> on that platform.
Bruce,
have you taken a look at my statistics collector stuff yet?
The view pgstat_activity shows datid, datname, procpid,
usesysid, usename and current_query per backend.
The code still needs some more work, but as it is it's ready
to apply as soon as 7.1 is out the door. All that is totally
OS independant, restricts the display of querystrings to
postgres superusers and works remotely.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
My apologies for all the pgmonitor crossposts. All future discussion should take place on the ports list. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane writes: > Mathijs Brands <mathijs@ilse.nl> writes: > > mathijs 297 0.1 0.2 6120 3352 pts/1 S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1 idle > > The interesting point about this is that the 7.0.3-on-2.7 installation > *is* managing to change its PS display. So either Solaris 2.8 > retrogressed (different predefined symbols maybe?), or we broke the code > since 7.0.3. I think I broke it. The deal on Solaris is this: There's SysV-style ps at /usr/bin/ps, and there's BSD-style ps at /usr/ucb/ps. The most obvious differences are the different argument style and the different output format. In true BSD style, the /usr/ucb/ps display can be changed by assigning argv[x] = "whatever". In true SysV style, the /usr/bin/ps display can (presumably) be changed with strcpy(argv[0], "whatever"). The old (pre-7.1) code only worked for BSD and had an exception case for Linux. The new code is mostly adopted from Sendmail. So in pre-7.1 you could get /usr/ucb/ps to work, while Sendmail apparently tried to get the SysV-style ps to work -- and failed(?). (This is generally the right direction, because the /usr/ucb stuff is obsolescent on Solaris, only for compatibility with SunOS 4.) The consequence should be: 1. check if sendmail works with /usr/bin/ps 2. a) if yes, figure out what got lost in PostgreSQL 2. b) if no, make the Solaris case in ps_status.c use the BSD approach -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Tom Lane writes: > > > Mathijs Brands <mathijs@ilse.nl> writes: > > > mathijs 297 0.1 0.2 6120 3352 pts/1 S 01:59:18 0:00 /opt/pgsql/bin/./postgres mathijs localhost template1idle > > > > The interesting point about this is that the 7.0.3-on-2.7 installation > > *is* managing to change its PS display. So either Solaris 2.8 > > retrogressed (different predefined symbols maybe?), or we broke the code > > since 7.0.3. > > I think I broke it. > > The deal on Solaris is this: There's SysV-style ps at /usr/bin/ps, and > there's BSD-style ps at /usr/ucb/ps. The most obvious differences are the > different argument style and the different output format. In true BSD > style, the /usr/ucb/ps display can be changed by assigning argv[x] = > "whatever". In true SysV style, the /usr/bin/ps display can (presumably) > be changed with strcpy(argv[0], "whatever"). > > The old (pre-7.1) code only worked for BSD and had an exception case for > Linux. The new code is mostly adopted from Sendmail. So in pre-7.1 you > could get /usr/ucb/ps to work, while Sendmail apparently tried to get the > SysV-style ps to work -- and failed(?). (This is generally the right > direction, because the /usr/ucb stuff is obsolescent on Solaris, only for > compatibility with SunOS 4.) > > The consequence should be: > > 1. check if sendmail works with /usr/bin/ps > > 2. a) if yes, figure out what got lost in PostgreSQL > > 2. b) if no, make the Solaris case in ps_status.c use the BSD approach [ I had tried to move this discussion to ports, but hackers is OK too.] Well, this is very interesting. I am glad to hear you based the current ps_status code on sendmail, which I think is the perfect way to go. I seem to remember the Solaris manual page stating it doesn't update the ps display, but I may be mixing that up with something else. I agree /usr/bin/ps is the better option, if we can get it working. Most people will not remember to use /usr/ucb/ps. I just uploaded a 0.34 version that allows the 'ps' command to be customized by editing the script. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
* Karel Zak <zakkr@zf.jcu.cz> [010329 03:10] wrote: > On Wed, Mar 28, 2001 at 04:10:52PM -0800, Alfred Perlstein wrote: > > * Tom Lane <tgl@sss.pgh.pa.us> [010328 16:07] wrote: > > > Larry Rosenman <ler@lerctr.org> writes: > > > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms > > > > including UnixWare. The UnixWare code will need /dev/kmem permission to > > > > change it's stuff, so I don't know whether we want to do this or not, but > > > > if people are looking at the ps stuff, please look at this as well. > > > > > > Well, *I* sure wouldn't run Postgres with write permission on /dev/kmem. > > > Especially not just to make ps_status work... > > > > Wow... is this all for "pgmonitor"? > > > > sorry, just my opinion... > > > > If it for pgmonitor then you guys ought to just mark it broken on > > these platforms, the non-"ps based" solution could have been > > implemented with all the time wasted trying to get the "ps based" > > hack working. :( > > If is still a mind for (IMHO) terrible work with 'ps'... not sure if > it's interesting, but exist cross-platforms library for processes > information loading - the libgtop. Supports: > > * All versions of Linux > * FreeBSD, NetBSD and OpenBSD > * BSD/OS > * Digital Unix > * Solaris > * ..and may be others > > Sure, it's in C :-) And infected with the GPV, not even the LGPV... not worth it. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
Bruce Momjian writes:> > Tom Lane writes:> > The consequence should be:> > > > 1. check if sendmail works with /usr/bin/ps>> > > 2. a) if yes, figure out what got lost in PostgreSQL> > > > 2. b) if no, make the Solaris case in ps_status.cuse the BSD> > approach> > [ I had tried to move this discussion to ports, but hackers is OK> too.]> > Well,this is very interesting. I am glad to hear you based the> current ps_status code on sendmail, which I think is theperfect> way to go.> > I seem to remember the Solaris manual page stating it doesn't> update the ps display, but I maybe mixing that up with something> else. I agree /usr/bin/ps is the better option, if we can get it> working. Most peoplewill not remember to use /usr/ucb/ps. I've done a quick survey of the Suns available to me to see whether sendmail updates the ps display. The summary is: 1) Require "/usr/ucb/ps w" at least. /usr/bin/ps has no options that I can find to display the status of sendmail. 2) Older versions of sendmail do not update the status. 8.6 does not update, 8.8.8 does. 3) Solaris 2.5 and 2.5.1 have sendmail 8.6, 7 has 8.9.1, 8 has 8.9.3. Some 2.6 have 8.6, others have 8.8.8. Presumably patches have beed applied. On other OSs, AIX 4.1, 4.2, 4.3 have sendmail 8.8.4, 8.8.6, 8.8.8 or 8.9.3. They all display the status in both SysV and BSD modes. On AIX there is one ps command which handles both styles. IRIX 6.2 and 6.5.4m through 6.5.10m have sendmail 8.8.8, 8.9.1, 8.9.3. No status is available. There do not appear to be any BSD-ish ps options. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
On Fri, Mar 30, 2001 at 11:07:25AM +0100, Pete Forman allegedly wrote: > I've done a quick survey of the Suns available to me to see whether > sendmail updates the ps display. The summary is: > > 1) Require "/usr/ucb/ps w" at least. /usr/bin/ps has no options > that I can find to display the status of sendmail. > > 2) Older versions of sendmail do not update the status. 8.6 does > not update, 8.8.8 does. > > 3) Solaris 2.5 and 2.5.1 have sendmail 8.6, 7 has 8.9.1, 8 has > 8.9.3. Some 2.6 have 8.6, others have 8.8.8. Presumably > patches have beed applied. > > On other OSs, AIX 4.1, 4.2, 4.3 have sendmail 8.8.4, 8.8.6, 8.8.8 or > 8.9.3. They all display the status in both SysV and BSD modes. > On AIX there is one ps command which handles both styles. > > IRIX 6.2 and 6.5.4m through 6.5.10m have sendmail 8.8.8, 8.9.1, 8.9.3. > No status is available. There do not appear to be any BSD-ish ps > options. The way /usr/ucb/ps in Solaris extracts the status for a process requires root rights and is (in my opinion) pretty gross. What it does is read the pseudo-file /proc/<pid/as, which is actually the memory used by the program. /usr/bin/ps only accesses /proc/<pid>/psinfo, which contains the real parameters supplied to the program and not the clobbered version. Regards, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum