search

USEPA / EPA_MOVES_Model

Estimating emissions for mobile sources
Other
80 stars 20 forks source link

Running MOVES3 on Linux #25

Closed DEQjpowell closed 2 years ago

DEQjpowell commented 3 years ago

I installed MOVES 3.0.1 on Linux. I run 

[jpowell@lpdeqappl01 ~]$ cat go.sh
#!/bin/sh
cd /opt/MOVES3
./ant/bin/ant run -Drunspec=/opt/MOVES3/testdata/Task1806.mrs
[jpowell@lpdeqappl01 ~]$ ./go.sh

What I expect: the model should run using the runspec I supplied. What happens instead: a lot of errors happen. For example, this one is the first error: 

[jpowell@lpdeqappl01 research-log]$ ./go.sh
Buildfile: /opt/EPA_MOVES_Model/build.xml

run:
    [java] 6/28/21, 4:02 PM INFO: Loading system configuration...
...
    [java] 6/28/21, 4:02 PM RUN_ERROR: External generator does not
    exist: /opt/EPA_MOVES_Model/generators\externalgenerator64.exe
    [java] 6/28/21, 4:02 PM RUN_ERROR: Unable to run external generator in BaseRateGenera$
    [java] 6/28/21, 4:02 PM INFO: Statements done: 0

and the next one is the last error: 

    [java] Bundle 20 (worker lpdeqappl01.entlinux.or.gov/616567159632095093) Error executing: SELECT * INTO OUTFILE '/opt/EPA_MOVES_Model/WorkerFolder/WorkerTemp25/BaseRateOutput.tbl' FROM BaseRateOutput
    [java] Can't create/write to file '/opt/EPA_MOVES_Model/WorkerFolder/WorkerTemp25/BaseRateOutput.tbl' (Errcode: 13 "Permission denied")
    [java]
[....]
BUILD SUCCESSFUL
Total time: 2 minutes 24 seconds

I am hoping that I can ignore the external generator error - MOVES does ignore it and past experience allows me hope there. Past experience and an EPA document from 2011 [1] suggest that the last error, "Can't create/write", cannot be ignored and cannot be overcome without breaking the Unix security model.

I have searched for help in the only relevant documents I can find ([1], [2]). It seems to be mentioned on the last slide of [1], but the slide trails off with "…" and the suggested workarounds (chmod, umask) do not seem to help. The SMOKE document does not mention the permissions problem (errno 13) at all.

A workaround is perhaps to run MOVES as the user 'mysql'. However, this does break the Unix security model.

I beg the community for a better workaround, if one is known, and I respectfully suggest to the MOVES team that they might move away from this model where the MariaDB process is expected to write files into directories created by the Java process, and instead use the sockets-based IPC mechanism in a future release. linux-moves-2011.pdf smoke-moves-install-instructures-linux-snapshot-2016-11-02.pdf

References (PDFs attached) [1] EPA, "Installing and Running MOVES on Linux", MOVES Work-group, June 15, 2011 [2] SMOKE-MOVES, "Installing MOVES2014a on Linux", Catherine Seppanen, 30 Dec 2015

danielbizercox commented 3 years ago

The external generator error is fatal, as MOVES uses the results of the generator as the basis for all subsequent calculators.

MOVES has two components written in Go that need to be compiled when not using the Windows installer: the external calculator and external generator ("external" to the core Java/SQL code of the model). After making sure that ant\bin and the Go compiler are on your PATH, run the command ant go, which will compile the go executables. You can check to make sure this worked by looking in the \calc and \generators directories for an executable called externalcalculatorgo64 and externalgenerator64 (with no extension).

You'll then want to set update the config files to point to the Linux executables (i.e., the ones without the extension). Set generatorExePath = generators\externalgenerator64 in:

Set calculatorApplicationPath = calc\externalcalculatorgo64.exe in:

As for the permissions error, did you set the required MariaDB configuration settings listed in https://github.com/USEPA/EPA_MOVES_Model#readme? The secure-file-priv='' setting lets MariaDB read and write files outside of the data directory.

DEQjpowell commented 3 years ago

Thank you! Your advice about how to operate the 'go' compilation process and change the .exe path is very valuable.

However we did make the secure-file-priv setting and we still see this error. The secure-file-priv allows MariaDB to write outside of its data, but in Unix more than that is needed. The java process is creating directories and subdirectories and expecting MariaDB to be able to create and write into files in those directories. That is I think virtually impossible in Unix.

Would anyone who has succeeded in running MOVES 3.0.1 (or even MOVES2014b) on Unix/Linux be able to state how they approached this problem?

DEQjpowell commented 3 years ago

We have tried the workaround of changing the user of the mysqld job over to the user who is firing off the java job. The errors disappear in this case. This is what I meant by "breaking the Unix security model" - mysql is effectively no longer multiuser.

danielbizercox commented 3 years ago

Unfortunately, the MOVES design team does not have the resources to fully support Unix. However, we have successfully run MOVES on Ubuntu with the configuration changes I just posted to the dev/v3.0.2 branch without running as the mysql user. So perhaps it is only certain Unix operating systems that require this workaround?

DEQjpowell commented 3 years ago

Hi Daniel,

Thank you for letting me know. I have a sense from the SMOKE-MOVES documentation and in general that others have had the easy experience you describe. I do not understand how that could be though, with the interprocess communication happening through the file system, and with the normal user creating directories that mysql is then asked to create files inside of. Are you running the MOVES java app as a normal user – not root, not privileged in any way? Are you running mysqld as the mysql user and not as root or privileged in any way? Did you have to muck with umask or setuid or any such thing?

Thank you,

From: Daniel Bizer-Cox @.> Sent: Monday, July 26, 2021 9:19 AM To: USEPA/EPA_MOVES_Model @.> Cc: POWELL James * DEQ @.>; Author @.> Subject: Re: [USEPA/EPA_MOVES_Model] MOVES 3.0.1 requires that you be user mysql to run it. (#25)

Unfortunately, the MOVES design team does not have the resources to fully support Unix. However, we have successfully run MOVES on Ubuntu with the configuration changes I just posted to the dev/v3.0.2 branch without running as the mysql user. So perhaps it is only certain Unix operating systems that require this workaround?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/USEPA/EPA_MOVES_Model/issues/25#issuecomment-886843477, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQYVSP5FA3PIPWDVABCM3SLTZWDH3ANCNFSM47VVZKDQ.

EvanGrahamMurray commented 3 years ago

When the MOVES design team was able to successfully run MOVES on Ubuntu, it was with the default installation settings aside from those noted in the dev/3.0.2 branch. For the most part, all dependencies like MySQL were installed via sudo, using default configurations, and we ran MOVES as a normal user.

One thing to check could be the ProtectHome setting for MySQL (probably in /etc/systemd/system/mysql.service). It should be set to false, so that the MySQL user can write to directories like /home, /root, and /run/user. I think most, if not all, MOVES installations would be in one of those locations or their subdirectories.

If that fails, I would check the permissions of directories that the MySQL user will need to access (like SharedWork, WorkerFolder, and MOVESTemporary) and, if needed, relax them. We didn't do this, but it could help in theory. One note of caution: I'm not sure how folders created in those directories get their permissions - if they don't inherit them from their parent, I don't think any solutions based on chmod or something similar would work.