0

I've read a bunch of systemd dependencies related on the web but still couldn't come up with one that works. I'm not sure what the problem is. The job is supposed to start on on reboot. It depends on network, autofs, rpc, and I've added a RequiresMountsFor, but still no luck. The unit still couldn't find a file on the network drive. Any ideas appreciated.

$ systemd-analyze critical-chain hello.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

hello.service @11.520s
└─autofs.service @11.429s +88ms
  └─network.target @11.425s
    └─network.service @10.751s +674ms
      └─NetworkManager.service @1.326s +123ms
        └─basic.target @1.274s
          └─sockets.target @1.274s
            └─rpcbind.socket @1.274s
              └─sysinit.target @1.273s
                └─systemd-update-utmp.service @1.269s +2ms
                  └─auditd.service @1.204s +62ms
                    └─systemd-tmpfiles-setup.service @1.120s +82ms
                      └─rhel-import-state.service @1.111s +8ms
                        └─local-fs.target @1.109s
                          └─home.mount @734ms +261ms
                            └─dev-mapper-centos\x2dhome.device @734ms

This is the unit file:

$ cat hello.service
[Unit]
Description=Hello Tester
Requires=network-online.target autofs.service
After=network-online.target autofs.service
RequiresMountsFor=/path/to/file

[Service]
ExecStart=/usr/bin/ls -l /path/to/file/on_nfs > /tmp/hello_tester.log

[Install]
WantedBy=multi-user.target

Here's the error. I guess I can't specify that cmd line with multiple args like that. But it is apparent that it can't see the file on the network when start up.

$ systemctl status hello.service
● hello.service - Hello Tester
   Loaded: loaded (/etc/systemd/system/hello.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2016-07-30 02:18:02 HKT; 2 days ago
  Process: 1760 ExecStart=/usr/bin/ls -l /path/to/file/on_nfs > /tmp/hello_tester.log (code=exited, status=2)
 Main PID: 1760 (code=exited, status=2)

Jul 30 02:17:56 localhost.localdomain systemd[1]: Started Hello Tester.
Jul 30 02:17:56 localhost.localdomain systemd[1]: Starting Hello Tester...
Jul 30 02:18:02 localhost.localdomain ls[1760]: /usr/bin/ls: cannot access /path/to/file/on_nfs: No such file or directory
Jul 30 02:18:02 localhost.localdomain ls[1760]: /usr/bin/ls: cannot access >: No such file or directory
Jul 30 02:18:02 localhost.localdomain ls[1760]: /usr/bin/ls: cannot access /tmp/hello_tester.log: No such file or directory
Jul 30 02:18:02 localhost.localdomain systemd[1]: hello.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Jul 30 02:18:02 localhost.localdomain systemd[1]: Unit hello.service entered failed state.
Jul 30 02:18:02 localhost.localdomain systemd[1]: hello.service failed.
17
  • That clearly indicates that the file can not be accessed, so that is all you should focus on. Does it work for you to run ls -l /path/to/file/on_nfs directly from the shell? – Julie Pelletier Aug 1 '16 at 2:06
  • @Julie: yes, it does. Only doesn't work when this unit runs after reboot. – surfcode Aug 1 '16 at 4:41
  • Does that mount get loaded automatically when you boot the machine? – Julie Pelletier Aug 1 '16 at 4:45
  • yes, that's why I added dependency on autofs and rpcbind. – surfcode Aug 1 '16 at 4:46
  • and, the RequiresMountsFor – surfcode Aug 1 '16 at 4:46
0

Just for paranoia, have you tried to access this file while logged in as user root? The root user doesn't have God rights when on an NFS partition unless the serving machine has granted them.

4
  • nope, I didn't login as 'root'. Normally, root user can also see this NFS partition without problems. – surfcode Aug 2 '16 at 6:32
  • So it was exported with no_root_squash by the server ? – Andrew Meredith Aug 2 '16 at 16:28
  • yes, with that export – surfcode Aug 4 '16 at 1:16
  • The "cannot access >" is, I am assuming because the ExecStart does not run the command through a shell, and so the file /tmp/hello_tester.log doesn't get created. However, the log entry "cannot access /path/to/file/on_nfs" needs to be got round first. I wonder if this is a timing thing. It can take a little while to establish an automount. Maybe if you added the clauses to retry the service on failure, you'll catch it the second/third time round. – Andrew Meredith Aug 5 '16 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.