error saying exceeded file size

[marvin51796]

I have just migrated everyting from one server onto a new server, when doing an IGNITE image of just the OS VG i am getting an error message.

 /opt/ignite/data/scripts/make_sys_image[142]: 1729 Exceeded file size limit(coredump)
ERROR:   The gzip command failed (exit status 162).

my current ulimit -a is setup like

time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         1048576
stack(kbytes)        8192
memory(kbytes)       unlimited
coredump(blocks)     4194303
nofiles(descriptors) 2048

any help or ideas would be appreciated...11vi3 patched to march 2015 QPK. on a BL870ci2.

thanks

[Patrick Wallek]

There are a couple of possibilites here:

1) The version of 'gzip' you have is VERY old and can't handle files larger than 2 GB.  On older versions of HP-UX, they cam with gzip version 1.2.4 (I think) which couldn't generate a .gz file larger than 2 GB.  The fix was to install a newer version of gzip that didn't have that issue.

2) The file system you are trying to store your Ignite-UX image on does NOT have largefiles enabled.  To check, use the 'fsadm' command.  For example:

# fsadm /var
fsadm: /etc/default/fs is used for determining the file system type
largefiles

Substitute your file system mountpoint for "/var" in the command above.  If the file system  does NOT support largefiles it will say 'nolargefiles'.

In my opinion, #2 is the more likely culprit than #1.

[marvin51796]

option 1 all show largefiles /var/opt/ignite and /var/opt/ignite/recovery....and since all the other servers are working ok, i am not sure that is it...

option 2 i am still looking into..

[Patrick Wallek]

How large is the backup file for this server at the time of the failure?

Is there any additional information in the log file for this server?  Check on your ignite server in /var/opt/ignite/clients/<server name>/recovery/latest/recovery.log

[marvin51796]

the gzip version 1.4 on both the server and the backup server.

[marvin51796]

here is what is says at the bottom..

       * Preparing to create a system archive.
       * The archive is estimated to reach 8060945 kbytes.
       * Free space on /var/opt/ignite/recovery/arch_mnt
         after archive should be about 79255037 kbytes.

       * Archiving contents of test001 via tar to
          /var/opt/ignite/recovery/arch_mnt/2015-07-13,14:35.
/opt/ignite/data/scripts/make_sys_image[142]: 49397 Exceeded file size limit(coredump)
ERROR:   The gzip command failed (exit status 162).

ERROR:   The make_sys_image command failed. The system recovery archive will
         not be created.


=======  07/13/15 14:48:24 EDT  make_net_recovery completed unsuccessfully

[Bill Hassell]

gzip is not handling the filesize limit very well.

The default limit for a VxFS filesystem is 2 GB (I know, a very poor default for modern computers).

If you don't initialize the filesystem with largefiles, 2GB is the limit and gzip will core dump.

You can see this setting instantly for all mountpoints using bdfmegs -v (attached).

[Dennis Handly]

> /opt/ignite/data/scripts/make_sys_image[142]: 1729 Exceeded file size limit(coredump)
>ERROR:   The gzip command failed (exit status 162).
>my current ulimit -a is setup like: file(blocks)         unlimited

It seems contrary to your ulimit(1) output, all these indicate that you have a ulimit(1) on file.

Otherwise gzip would just get EFBIG.

You might want to put that "ulimit -a" inside make_sys_image before line 142.

Exit status 162 = 128 + 34, SIGXFSZ.

What does file(1) show for your corefile?

>the gzip version 1.4

This should handle largefiles since 1.3.5 does.

[Steven Schweda]

   I know nothing, but ...

> >the gzip version 1.4
> This should handle largefiles since 1.3.5 does.

   True, but many things are possible.  As of version 1.5, "gzip -V"
doesn't say anything about large-file support.  I'd expect large-file
support to be enabled in gzip on any reasonable UNIX system, but some
versions of HP-UX have that bug in mkstemp() which might affect gzip.
(Check the gzip source for "mkstemp"?)

   The other questions would be which gzip executable is used by the
Ignite softeare, and if it's the same as the one you're getting the
version for.

[Steven Schweda]

> [...] but some
> versions of HP-UX have that bug in mkstemp() which might affect gzip.
> (Check the gzip source for "mkstemp"?)

   On the bright side, Looking at the gzip 1.5 code, I see "mkstemp" in
some header files, but not in any ".c" files, so we could be safe from
that one.

[Bill Hassell]

Patrick wrote:

>> # fsadm /var
>> fsadm: /etc/default/fs is used for determining the file system type
>> largefiles

Did you run this command? Did it report nolargefiles?

[marvin51796]

i ran the fsadm /var command on ALL mount points on both the ignite server and the server i am trying to get an iso image of it they ALL reported back largefiles.

fsadm: /etc/default/fs is used for determining the file system type
largefiles

I also verified that Gzip is at level 1.4 its the open_gzip version.

???

[Bill Hassell]

What does:

bdf /var/opt/ignite/recovery/archives

report?

Are you using a fake disk (ie, NFS or CIFS or NAS-something) for the archives?

[marvin51796]

recovery shows

 /dev/vgignite/ignite
153600000 96434377 53707746 64% /var/opt/ignite
/dev/vgignite/recovery
346939392 259627813 81908351 76% /var/opt/ignite/recovery

We are NFS mounting the ignite server to the server getting backed up... we have 15 other servers that this is running on just fine..ran 3 images last night with issue .

thanks

[marvin51796]

Something else to note, i ran this as raot manually and it worked yesterday?

-rw-------   1 bin        sys        6091264806 Jul 13 13:06 2015-07-13,12:35

[Bill Hassell]

Check dmesg and also /var/adm/syslog/syslog.log for any errors.

Note: This is what bdfmegs reports for your Ignite volumes:

File-System             Mbytes    Used   Avail %Used Mounted on
/dev/vgignite/ignite     146.5g   92.0g   51.2g  64% /var/opt/ignite
/dev/vgignite/recovery   330.9g  247.6g   78.1g  76% /var/opt/ignite/recovery

A bit easier to read...

[Patrick Wallek]

What version of HP-UX is the server that is getting backed up?  Are both it and the Ignite server 11.31?

[marvin51796]

they are both

 IGNITE                        C.7.18.63      HP-UX Installation Utilities (Ignite-UX)

[marvin51796 · Accepted solution]

ALL

 i want to thank all of you for all the help and ideas...we have found the root cause of the problem..my boss..LOL...

apparently one day when i was off he found an issue where the cronjobs were running an hour later than they were supposed to , so he stopped and restarted cron, the problme was that he was sudo'd into root, not logged into root directly. So once i stopped and restarted cron things started working correctly and on the correct time.

thanks again for all your help.

[Dennis Handly]

>he was sudo'd into root

Can he try this again and do "ulimit -a" after the sudo?

[Patrick Wallek]

How he sudo'd to root may have an impact on the environment he gets.  'sudo su' vs. 'sudo su -' would likely yield different results.

From the 'su' man page:

      su recognizes the following options:

           -         If the - option is specified, the new shell starts up
                     as if the new user had initiated a new login session.
                     If the - option is omitted, the new shell starts as if
                     a subshell was invoked.  See more details below.

 <...snip out the '-d' option info...>

      If the - option is specified, the new shell starts up as if the new
      user had initiated a new login session.  Exceptions are as follows:

        +  The HOME variable is reset to the new user's home directory.

        +  If the new user name is root, the path and prompt variables are
           reset:

           PATH=/usr/bin:/usr/sbin:/sbin
           PS1=#

           For other user names:

           PATH=/usr/bin
           PS1=$

        +  The TERM variable is retained.

        +  The rest of the environment is deleted and reset to the login
           state.  However, the login files are normally executed anyway,
           usually restoring the expected value of PATH and other variables.

      If the - option is omitted, the new shell starts as if a subshell was
      invoked.  Exceptions are as follows:

        +  If the new user name is root, the path and prompt variables are
           reset:

           PATH=/usr/bin:/usr/sbin:/sbin
           PS1=#

        +  The previously defined HOME and ENV environment variables are
           removed.

        +  The rest of the environment is retained.

I have never had a problem with my environment when using 'sudo' to become root on a server, but then I always do 'sudo su -'.