Files in Custom/Kernel are (initially) not loaded in docker installations.

[svenoe]

After installing a package with a file in Custom/Kernel/[...] and then adding some debugging output to said file (print STDERR), the output is not shown (the modified file is not loaded), until I change the same file in Kernel/[...]. I'm not sure whether this problem is present for the file added by the package straight from installation, or whether it only affects my manual editing of it.

In any case, I guess nginx only checks for file changes in Kernel, or something like that. @bschmalhofer I'm assigning it to you, if you don't have time, you can give it back to me, but maybe you could give me a hint on where to look. :)

[bschmalhofer]

Hi @svenoe ,

I will take a look at this. Obviously the modified checking is done by Gazelle, not by Nginx.
I need to check how Apache/mod_perl does this in OTOBO 10.0.x. I can imagine that it doesn*t work there either, as Apache::Reload might also check only whether already loaded modules have changed. And in this case, the file that is already loaded did not change.

[bschmalhofer]

Refreshing changed Perl modules is mainly a question what is checked how often. I investigated how it is currently done.

• OTRS 6 and OTOBO 10 running under Apache/mod_perl

Apache2::Reload looks for every request whether the files referenced in %INC have changed

• otobo.psgi

Check whether ZZZAAuto.pm has changed for every request. Check all other modules every 10s.

Neither approach checks for whether a module with the same package name has been installed in a different location. (But it might have been solved in KIXCore)

Several solutions are possible:

1. require a webserver restart, or force fresh webserver processes, when a module was installed
2. Do not allow overriding core modules
3. Trigger a refresh when modules are copied into Kernel/Custom
4. Watch the complete directory tree, and go to 1.
5. Trigger a refresh in the CodeInstall section of the OTOBO package

Regarding 1,: this is not user friendly.

Regarding 2.: My favourite solution would be 2.. Not overriding core modules is best practice anyways.
However, this would be a major change that breaks things.

Regarding 4.: This is probably not appropriate for production

Regarding 5.: places a burden on extension developers, which is a bad thing to do.

I don't see much speaking against solution 3. . This would be fairly small change in Kernel::System::Package::_FileInstall(). Let's try this.

[bschmalhofer]

Hi @svenoe,
I added the touching of the core module in the branch issue-#666-dark_forces_touching_the_core. Could you check whether that branch works for you?

Best regards,
Bernhard

[bschmalhofer]

@svenoe I assigned this to you because I thing a second pair of eyes is useful here.

[svenoe]

Works for me. :)

(Just copied a file to Custom/Kernel/Modules and modified it.)