This unit $ cat /etc/systemd/system/noip-duc.service [Unit] Description=No-IP Dynamic Update Client After=network.target auditd.service
[Service] EnvironmentFile=/etc/sysconfig/noip-duc ExecStart=/usr/local/bin/noip-duc Restart=on-failure Type=simple
[Install] WantedBy=multi-user.target always fails at boot time with the message status=2/INVALIDARGUMENT
Here is an extract from the system log (a fuller extract is attached): Mar 18 07:57:56 OaklandWeather.localdomain systemd[1]: Started noip- duc.service - No-IP Dynamic Update Client. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Failed with result 'exit-code'. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Scheduled restart job, restart counter is at 1. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: Stopped noip- duc.service - No-IP Dynamic Update Client. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: Started noip- duc.service - No-IP Dynamic Update Client. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Failed with result 'exit-code'. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Scheduled restart job, restart counter is at 2.
However if the unit is started from the console after the boot process is complete: $ systemctrl start noip-duc.service it succeeds. How can I find out what the argument is with which systemd is invoking noip-duc, so I can understand why it is invalid at boot time but valid when the unit is started afterwards from the console? I would simply recompile it to output this, but noip-duc is written in the rust programming language, which I to lazy to learn for this one application.
Once upon a time, Jonathan Ryshpan jonrysh@pacbell.net said:
This unit $ cat /etc/systemd/system/noip-duc.service [Unit] Description=No-IP Dynamic Update Client After=network.target auditd.service
This should probably be network-online.target.
always fails at boot time with the message status=2/INVALIDARGUMENT
That's the exit code from the program. It is probably the return code from a system call made within the program, not in response to some command-line argument. But if the program runs before the network is up and doesn't handle waiting, that's the most likely culprit.
On Sun, 2023-04-30 at 16:41 -0500, Chris Adams wrote:
Once upon a time, Jonathan Ryshpan jonrysh@pacbell.net said:
This unit $ cat /etc/systemd/system/noip-duc.service [Unit] Description=No-IP Dynamic Update Client After=network.target auditd.service
This should probably be network-online.target.
always fails at boot time with the message status=2/INVALIDARGUMENT
That's the exit code from the program. It is probably the return code from a system call made within the program, not in response to some command-line argument. But if the program runs before the network is up and doesn't handle waiting, that's the most likely culprit.
A very plausible theory. I was sure this would fix the problem; but it is not so. I edited /etc/systemd/system/noip-duc.service as you recommend. The file noip-duc.service has been edited to change After=network.target auditd.service to After=network-online.target auditd.service
And the problem remains. Further advice would be welcome.
On Mon, 01 May 2023 13:39:29 -0700 Jonathan Ryshpan wrote:
And the problem remains. Further advice would be welcome.
Without ever managing to determine what the problem was, I have sometimes resorted to disabling the service, then making an rc.local script that uses the "at" command to start the service 10 or 20 seconds from "now".
On 1 May 2023, at 22:41, Tom Horsley horsley1953@gmail.com wrote:
On Mon, 01 May 2023 13:39:29 -0700 Jonathan Ryshpan wrote:
And the problem remains. Further advice would be welcome.
Without ever managing to determine what the problem was, I have sometimes resorted to disabling the service, then making an rc.local script that uses the "at" command to start the service 10 or 20 seconds from "now".
You need ti run the program in its debug mode to show you what it is up to when it detects an error.
If the code is not designed to be debugged then you could try running it under strace to find out what system call it makes that returns the EINVARG.
Barry
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I have something like this in my rc.local for similar reasons. ( sleep 30 ; cd /someplace ; <somecommand> ) &
On Mon, May 1, 2023 at 4:41 PM Tom Horsley horsley1953@gmail.com wrote:
On Mon, 01 May 2023 13:39:29 -0700 Jonathan Ryshpan wrote:
And the problem remains. Further advice would be welcome.
Without ever managing to determine what the problem was, I have sometimes resorted to disabling the service, then making an rc.local script that uses the "at" command to start the service 10 or 20 seconds from "now". _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, 1 May 2023 18:23:08 -0500 Roger Heflin wrote:
I have something like this in my rc.local for similar reasons. ( sleep 30 ; cd /someplace ; <somecommand> ) &
I'm surprised that works. I used to have that sort of thing directly in rc.local, then they converted the code that runs rc.local to a systemd unit which "helpfully" killed things that were taking "too long", so I switched to an "at" command to run a different script "now", and moved all my delays into the different script (which is now running out from under the thumb of systemd).
On 4/30/23 14:25, Jonathan Ryshpan wrote:
Here is an extract from the system log (a fuller extract is attached): Mar 18 07:57:56 OaklandWeather.localdomain systemd[1]: Started noip-duc.service - No-IP Dynamic Update Client. Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
I would assume it's not finding the interface that it wants to check for the IP address. You could try adding "RestartSec=20" to the service file. That way it will give more time before failing. If that doesn't work, then it's more likely some sort of permissions issue.