Feedback
Did this article resolve your question/issue?

   

Article

Recheck user permissions messages when using PROUTIL increaseto

« Go Back

Information

 
TitleRecheck user permissions messages when using PROUTIL increaseto
URL NameP186535
Article Number000169831
EnvironmentProduct: OpenEdge
Version: 10.1C, 10.2x, 11.x
OS: All supported platforms
Question/Problem Description
How to work with messages to "recheck user permissions" when using increaseto ?
Recheck user permissions messages when using: PROUTIL -C increaseto
Cannot complete increasing database shared-memory startup parameters online when users are connected
Increasing -B -B2 -L -bibufs -aibufs -Mxs -omsize -mtpmsize -cdcsize online with PROUTIL -C increaseto
Steps to Reproduce
Clarifying Information
Error MessageThe database connections above have not attached to recently added shared memory segments. Do you wish to recheck? (y/n)
Do you wish to recheck user permissions and continue increasing parameters online?(y/n)
Defect Number
Enhancement Number
Cause
Resolution
This is how the implementation of the API to increase parameter values online is designed:

New shared memory (shm) segments have the same permissions as the .db file of the database. Which is why the user running PROUTIL increaseto needs to have security privileges on the directly connected database to use INCREASETO. Otherwise it will fail with:
Increase Params lacks proper permissions to create shared memory. (13969)

All users directly connected to the database must have privileges to read any new shared-memory segments created by INCREASETO. If a user does not have access, INCREASETO will prompt you to disconnect the under-privileged users or abort the INCREASETO:
  • All server processes will connect to the newly added shared memory segments within 3 seconds. This includes shared memory connected AppServers, Secondary login brokers, Remote Servers, etc
  • Self service connections will attempt to connect to the newly added shared memory segment the next time they "cross the RDBMS line". In other words, they need to be actively doing something on the server side to connect. 
Once shared-memory connections have connected to the database they downgrade their suid privileges and only have their user privileges or that of the forked process thereafter. If the user privileges are not sufficient to connect to the newly added shared memory segment then the increaseto cannot continue until they disconnect. In order that when they re-connect initially with their suid privileges, they can attach to shared memory segments again.

In order for shared memory parameter increase to succeed, when an increaseto instruction is stalled by the following messages, two Options are available:
The database connections above have not attached to recently added shared memory segments. Do you wish to recheck? (y/n)
Do you wish to recheck user permissions and continue increasing parameters online?(y/n)

 
OPTION 1: Choose "n" not to wait and re-run the same PROUTIL increaseto at a later stage when the existing connections have been reviewed.

OPTION 2: Choose "y" to wait for all connections to refresh their shared memory connection. In a production scenario, this is likely the best option unless the connections are:
 
a. A PROMON session
b. Sessions that remain left without activity

This behaviour is best demonstrated by way of an example on a 32-bit version for simplicity in values used:

1. Create and start a test database:
$   prodb test sports2000
$   proserve test -B 3000 -shmsegsize 128

What do shared memory segments look like currently?
 
$  PROMON test > R&D > 1. Status Displays > 14. Shared Memory Segments

Status: Shared Memory Segments
Seg              Id                Size             Used              Free
   1   43384832     18112680     16016216      2096464
 
  • QUIT the PROMON session here and every time referenced below. 
  • The reason to quit PROMON sessions, is that the exception on connected users is the 'PROMON' connection which must be disconnected in order for the shared-memory to be increased through the addition of a new shared-memory segment
2. Start two self-service client sessions:
 
$  prowin32 test
.. and do nothing

$  prowin32 test
... and run a simple update:
FIND LAST customer.
UPDATE NAME = "hello you!".
DISPLAY NAME.

3. Make a small increase to shared memory parameters:
 
$ proutil test -C increaseto -L 10000
Increase Params increasing lock table size (-L) from 8192 to 10016. (13979)

How has this changed the shared memory segments:
 
$   PROMON test > R&D > 1. Status Displays > 14. Shared Memory Segments

Status: Shared Memory Segments
Seg               Id               Size             Used              Free
   1   43384832     18112680     16177208      1935472

Result:
  • Lock Table size has been increased
  • The current shared memory segment adjusted, no need for self service clients to reattach. 
  • Sessions that are have no activity are not blocking the increase.

4. Make a larger increase to shared memory parameters:
 
$ proutil test -C increaseto -B 3512

Waiting for Broker connection to newly added shared memory segments. (14269)
     Usr     Name     Type       Pid
       6      auser ABL          1484
       7      kuser ABL          5720
The database connections above have not attached to recently added shared memory segments
Do you wish to recheck? (y/n)
 
<do nothing at this stage>
              
Why do the connected users message appear when they did not previously?
  • The 'increaseto' value requires a new shared memory segment to be allocated. 
  • This new shared memory segment can be immediately seen after running 'increaseto'. It is not using it yet as existing connections have not connected to the shared memory.
  • Any user that connects immediately after the increaseto cmd was run, will not be listed in the above message reporting connected users.
 
$   PROMON test > R&D > 1. Status Displays > 14. Shared Memory Segments

Status: Shared Memory Segments
Seg               Id               Size             Used              Free
   1   43384832     18112680     16180024      1932656
   2   67960832    134217728    134217728            0

At this stage there are two Options:

Option 1: In the 'increase to' prompt select "n" to not recheck and re-run increaseto
 
Do you wish to recheck? (y/n)
n
Increase Params aborted because of shared memory allocation issue. (13977)

By exiting the increaseto session:
  • The new shared memory segment can still be seen in PROMON, Status: Shared Memory Segments, as it has been allocated but is not in use yet.
  • While allocated, we explicitly dissallow allocation attempts from this new segment until all connections are attached to it, in order to avoid a race condition.
  • Over time, these self service connections will either disconnect and re-connect, to reattach with their elevated suid before downgrading (as will any other new connection) or they will be connected to this newly added shm segment when existing connections run new serverside processing, even after the increaseto was cancelled.
  • Sessions that are left without activity will always continue to block an increaseto instruction which requires a new segment being added. Their sessions need to be disconnected.

5. Continuing the above example:
  • Disconnect the first client session (that did nothing)
DISCONNECT test.
  • Re-run the update in the second client session.
  • Remember to disconnect the PROMON session.
  • Re-run the 'increaseto':
$ proutil test -C increaseto -B 3512
Increase Params increasing buffer pools size (-B) from 3000 to 3512. (13980)

Result:

The new allocated shared memory segment is now able to be used as all the self service connections have attached to the new shared memory segment and it is now available:
 
$   PROMON test > R&D > 1. Status Displays > 14. Shared Memory Segments

Status: Shared Memory Segments
Seg               Id               Size             Used              Free

   1   40304640     18112680     18094728        17952
   2   66191360    134217728       328264    133889464

Option 2:  In the 'increase to' prompt select "y" to not recheck:
 
Do you wish to recheck? (y/n)
y
Connected users will continue to be listed until they 'do something' to re-address the shared-memory segments, otherwise they need to be disconnected.
 
6. Continuing the above example:
  • Disconnect the first client session (that did nothing)
  • Re-run the update in the second client session.
  • Make a new connection to the database (just for fun)
  • At the prompt, opt to wait again:
Do you wish to recheck? (y/n)
y
Increase Params increasing buffer pools size (-B) from 3000 to 3512. (13980)

Result:

The new allocated shared memory segment is now able to be used as all the self service connections have attached to the new shared memory segment and it is now available:
 
$  PROMON test > R&D > 1. Status Displays > 14. Shared Memory Segments

Seg               Id                Size             Used                Free
   1   40304640      18112680     18094728            17952
   2   66191360    134217728         328264    133889464
        
These responses can be provided for scripting purposes. Refer to Article:
Workaround
Notes
Progress Article: 

 What is proutil <dbname> -C  increaseto?   
 
Last Modified Date3/17/2021 1:06 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.