I should have mentioned I am working with the imap server on James, not pop3... Marc..
On 02/18/2019 05:26 PM, Marc Chamberlin wrote: > Thanks Matt, you were correct, I needed to install the java-devel > packages. Maven then ran fine, kinda scary actually watching it run! > That is a LOT of code being downloaded and processed! I will table the > systemd issue for now and just concentrate on getting James running. I > like your idea of using crontab to work around it for now... > > Any wise, I installed the new version of James 3.4 and got closer to > getting it up and running. I set it up with one domain and one user > (myself) and I can now send and receive email to/from myself on it. But > I cannot send an outgoing email to anywhere else! I am using Thunderbird > to test it with and when I try to send an outgoing email to some other > domain, something weird is happening. It acts as if it sent it OK, but > it is showing up in the sent folder, in Thunderbird, twice! I tried to > send an email from my account on James to a GMail account I have and it > never showed up, so something is failing still. > > Going in the other direction, if I send an email from an outside server > to my account on James, I do receive it OK. > > BTW this latest version of James did not fix the log file problems I > reported earlier. Marc.. > > On 02/18/2019 11:12 AM, cryptearth wrote: >> Well, for me, I just added "@reboot /path/to/james/bin/james start" to >> my root crontab - no need for init.d/systemd. >> As the issue arised after you let systemctl create files - seems >> something went wrong there. >> >> As for your maven issue: do you have java-devel installed? >> >> Matt >> >> Am 18.02.2019 um 03:40 schrieb Benoit Tellier: >>> I am not sure you can use "james script" directly like this as a initd >>> script. >>> >>> What we do use in docker (and thus is maintained) is >>> >>> ./bin/wrapper-linux-x86-64 conf/wrapper.conf wrapper.syslog.ident=james >>> wrapper.pidfile=var/james.pid wrapper.daemonize=FALSE >>> >>> Cheers, >>> >>> Benoit >>> >>> On 2/18/19 7:39 a ²M, Marc Chamberlin wrote: >>>> Hi Matt, thanks for responding! It appears to me that "classpath" is >>>> actually defined in the startup scripts. There are two different >>>> scripts >>>> used to start the james server, either "james" or "run.sh". I do not >>>> believe "classpath" is defined in any of the config files themselves. I >>>> am not using "run.sh" to start the james server, instead I noted that >>>> the james script is configured with the classic init.d entry points - >>>> start, stop, restart, etc. I modified the "james" script slightly so >>>> that I could run james as a systemd service instead (see below). At >>>> this >>>> point I strongly suspect that the definition of environment variables, >>>> using the james startup script, is failing, so I am pursuing this to >>>> see what is going on. However, running james as a systemd service does >>>> not seem to be the problem, even if I just run the james startup script >>>> by itself, not as a service, I am still getting the same failure with >>>> the "classpath" variable. >>>> >>>> If anyone has ported james to run as a systemd service I would much >>>> appreciate knowing how you did it. What I have done was to add the >>>> init.d initialization comments to the beginning of the james shell >>>> script then let systemd take it from there to create the actual >>>> .service >>>> files - >>>> added to beginning of the james startup script to define init.d >>>> runlevels - >>>> >>>> ### BEGIN INIT INFO >>>> # Provides: james >>>> # Required-Start: $network $syslog $time >>>> # Required-Stop: $network $syslog $time >>>> # Default-Start: 2 3 4 5 >>>> # Default-Stop: 0 1 6 >>>> # Description: Initscript for Apache James Mail Server >>>> ### END INIT INFO >>>> >>>> and FYI these are the steps I then took to set up the init.d services >>>> and then convert them to systemd services on OpenSuSE Leap 15.0 - >>>> >>>> First I created a soft link from /etc/init.d to the james startup >>>> script - >>>> >>>> ln -s /mail/apache-james-3.2/james-server-app-3.2.0/bin/james >>>> /etc/init.d/james >>>> >>>> Next install in james script into the various init.d runlevels >>>> >>>> cd /etc/init.d >>>> insserv james >>>> >>>> Next set up the systemd files from the new init.d configuration files >>>> and start the service. >>>> >>>> systemctl daemon-reload >>>> systemctl start james.service >>>> >>>> The james service does start up OK and will report that it is running >>>> when checking on it's status. It is just not working properly in >>>> accepting connections or doing the various tasks that the service >>>> should >>>> be doing and my goal at this point is to resolve any and all exceptions >>>> that are occurring such as this one. >>>> >>>> Marc... >>>> >>>> >>>> >>>> On 02/17/2019 06:01 AM, cryptearth wrote: >>>>> Hey Marc, Matt here. >>>>> >>>>> The provided stack only says that you given "classpath" to some >>>>> parameter wich expectes a url in some config file. So I guess it could >>>>> help if you also show the config where you set "classpath" so one can >>>>> figure out, if "classpath" is a legal input for the setting you set >>>>> it. >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-user-h...@james.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >> For additional commands, e-mail: server-user-h...@james.apache.org >> -- Linux Counter
