tobiasbrunner
commented
2 weeks ago It appears that StrongSwan is attempting to create routing table rules before the network is fully online.
Hm, that's a basic kernel feature that's configured via Netlink. No idea why that would be related to systemd's network-online.target, which waits for IPs to be configured on all interfaces etc. Could there be some other issue? Are there any other errors logged? (There should be a more specific Netlink error logged even in older versions. Increasing the log level for knl to 3 might show more about the communication.)
Maybe adding After=network.target has an effect in case network-online.target is not pulled in (see below)?
This adjustment ensures that StrongSwan waits until the network is online before starting, preventing the observed errors.
There already is a After=network-online.target that should do this, I guess. However, the target might not be pulled in if nobody requests it (to not delay the boot). This is what the systemd docs say about network-online.target:
Note that normally, if no service requires it and if no remote mount point is configured, this target is not pulled into the boot, thus avoiding any delays during boot should the network not be available.
And they go on:
It is strongly recommended not to make use of this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up). Its primary purpose is network client software that cannot operate without network.
So whether to explicitly add that Wants= might depend on the use case. I'm not sure if it's a good idea to add it by default.
I would like to understand the root cause of this issue and determine if there are any additional steps or checks that can be implemented to ensure reliable mounting of encrypted NFS volumes after a system reboot.
Please go ahead and do that then.
saicharansunkara-ibm
System (please complete the following information):
Describe the bug After a system reboot, I am experiencing failures when attempting to mount encrypted NFS volumes. The error message encountered is a connection timeout. The following journal logs are observed:
It appears that StrongSwan is attempting to create routing table rules before the network is fully online. This issue is intermittent but recurring. Adding the following directives to the StrongSwan systemd unit file seems to mitigate the issue:
This adjustment ensures that StrongSwan waits until the network is online before starting, preventing the observed errors.
To Reproduce Steps to reproduce the behavior:
I would like to understand the root cause of this issue and determine if there are any additional steps or checks that can be implemented to ensure reliable mounting of encrypted NFS volumes after a system reboot.