nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Perl executable turned 0 bytes

pinki

Hi,

The perl executable turns 0 bytes all of a sudden. I am facing this issue quite frequently. As a workaround I am copying the executable from other env. Can anyone help me to figure out what might be the root cause???

Solaris,TS 6.7.1

Thanks,
Pinki.

Find more posts tagged with

Comments

nipper

This is a common problem, exactly how it happens is unclear but typically someone (or some process) tries some unix style redirection to a perl script (like cat something > iwperl blah.ipl)

Most likely a process since it would have to have the full path (and permission to overwrite iwperl)

often it creates an iwperl which gets picked up in front of iwperl.exe

I wish I could help you figure out how it happens. But the good news is that it often takes hours or days to realize that iwperl is the issue.

HTH

Andy

Adam Stoller

Hi,

The perl executable turns 0 bytes all of a sudden. I am facing this issue quite frequently. As a workaround I am copying the executable from other env. Can anyone help me to figure out what might be the root cause???

Solaris,TS 6.7.1

Thanks,
Pinki.

You had this happen on Solaris?
Nipper's response is probably still the right one - but it sounds like someone imported / configured something using a Windows-style mentality since on Solaris you should just call the "script" and not ".../iwperl .../script" (like you do on Windows).

I would consider looking at all configurations for custom menu items, and all command settings for workflow External and/or URL Tasks (CGI Tasks shouldn't be an issue here) as well as inline scripts within DCTs -- those are the most likely places to find something like this being misconfigured.

pinki

Yeah this issue is with Solaris. We have added few new inline scripts in DCTs but how does this creates a problem? I am afraid if its a code problem or a general solaris issue.

Adam Stoller

Yeah this issue is with Solaris. We have added few new inline scripts in DCTs but how does this creates a problem? I am afraid if its a code problem or a general solaris issue.

As nipper indicated - the most likely cause of this is someone / something doing an incorrect re-direct - like:

% cat > iwperl foo.ipl

If the scripts are executable and have the correct #! line at the top, then there's no need for the "iwperl" part to appear anywhere within the command specification. The above is overly simplified. Another possibility is a script which tried to get it's name or method of invocation from a variable (e.g.:

or a URI string or some such) and somehow gets the iwperl engine instead of the script name.

The problem is - unless you manage to find the issue in front of your eyes, tracking it down could be a bit difficult.

Things I would consider doing:

Of course, if the problem occurred because someone fat-fingered a command line - you might never find the source of the problem because it might never happen again - so you might just wait until you know you have a repeatable case (and keep a handy copy of the iwperl binary around just in case) before you spend a lot of time trying to track it down.

nipper

I did not even notice it was Solaris

Here is an idea

chmod 555 /usr/iw-home/iw-perl/bin/iwperl

It will still be executable but not rightable (I think even root would fail but you can test it).

BTW, if what we think is happening (and it is in a workflow, script, something), then you are having some functionality missing on your system,

pinki

Thanks.. will try to monitor it for some days - try my luck to figure out the root cause of this.

nipper

Thanks.. will try to monitor it for some days - try my luck to figure out the root cause of this.

Count yourself lucky that you have found the problem. This manifests itself as a WF not working or templates not working and it takes hours or days to find that the perl executable is broken.

Adam Stoller

It will still be executable but not rightable

What, you think it fell down and can't get up again? ;-)

I believe the word you were looking for was: writable

(sorry, couldn't resist)

new2_report.rptdesign

Untitled.png

ISCBorisB

I did not even notice it was Solaris

Here is an idea

chmod 555 /usr/iw-home/iw-perl/bin/iwperl

It will still be executable but not rightable (I think even root would fail but you can test it).

BTW, if what we think is happening (and it is in a workflow, script, something), then you are having some functionality missing on your system,

Nobody would be ably to override 555 File, not even root. A little caveat though - some SP's or upgrade
installs may fail with this mode, I *believe* some of them install iw-perl/bin Components even if the new
Components are identical to the existing ones. Of course you can play the mode back right before the install, etc

Migrateduser

What, you think it fell down and can't get up again? ;-)

I believe the word you were looking for was: writable

(sorry, couldn't resist)

Dang it....I wanted so badly to jump on this. Too slow....

nipper

I wanted so badly to jump on this. Too slow....

Like you are telling us something we do not already know ?