Skip to content
This repository was archived by the owner on May 30, 2023. It is now read-only.

Enable remote-fs#612

Merged
krnowak merged 6 commits intomainfrom
krnowak/fix-remote-fs
Sep 26, 2020
Merged

Enable remote-fs#612
krnowak merged 6 commits intomainfrom
krnowak/fix-remote-fs

Conversation

@krnowak
Copy link
Copy Markdown
Contributor

@krnowak krnowak commented Sep 25, 2020 •
edited
Loading

Since v242 remote-fs.target was not enabled by default, so mounting NFS shares did not happen after the update from 2512 (which has systemd 241). The ebuild was enabling remote-fs though, by putting a symlink in /etc/systemd/system/…. But this change in `/etc/ is apparently propagated during update, so remote-fs.target ended up being not a dependent target during boot. So the PR tries harder at not enabling services through /etc, but through /lib.

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

The image is building for me at the moment, but:

find /build/amd64-usr/usr/lib/systemd/ | grep 'remote-fs'
/build/amd64-usr/usr/lib/systemd/system/remote-fs.target
/build/amd64-usr/usr/lib/systemd/system/remote-fs-pre.target
/build/amd64-usr/usr/lib/systemd/system/multi-user.target.wants/remote-fs.target # that used to be missing
/build/amd64-usr/usr/lib/systemd/system/remote-fs.target.wants
/build/amd64-usr/usr/lib/systemd/system/remote-fs.target.wants/var-lib-machines.mount

(in comparison with current stable)

Flatcar Container Linux by Kinvolk stable (2605.5.0)
core@localhost ~ $ find /usr/lib/systemd/ | grep remote-fs
/usr/lib/systemd/system/remote-fs.target.wants
/usr/lib/systemd/system/remote-fs.target.wants/var-lib-machines.mount
/usr/lib/systemd/system/remote-fs-pre.target
/usr/lib/systemd/system/remote-fs.target

Fixes flatcar/Flatcar#191

To be propagated to flatcar-2605 and flatcar-2632.

pothos
pothos reviewed Sep 25, 2020
View reviewed changes
pothos
pothos reviewed Sep 25, 2020
View reviewed changes
pothos
pothos reviewed Sep 25, 2020
View reviewed changes
pothos
pothos reviewed Sep 25, 2020
View reviewed changes
sys-apps/systemd/systemd-9999.ebuild
# Flatcar: Don't enable services in /etc, move to /usr.
systemd_enable_service multi-user.target systemd-networkd.service
systemd_enable_service multi-user.target systemd-resolved.service
systemd_enable_service multi-user.target remote-fs.target
Copy link
Copy Markdown
Contributor

@pothos pothos Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some other files are also missing, I guess we need something like this (unless upstream deprecated it):

multi-user.target machines.target
multi-user.target remote-cryptsetup.target
network-online.target systemd-networkd-wait-online.service
sockets.target systemd-networkd.socket

Copy link
Copy Markdown
Contributor Author

@krnowak krnowak Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering whether to basically translate all the preset stuff from systemd into system_enable_service. For now I did that only for remote-fs. Can update it here too.

Copy link
Copy Markdown
Contributor Author

@krnowak krnowak Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added multi-user.target machines.target and multi-user.target remote-cryptsetup.target. I also added remount-fs.target systemd-pstore.service. I don't know where did you get the other two - they are not listed in upstream's preset file.

Copy link
Copy Markdown
Contributor

@pothos pothos Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They come from the 2512.5.0 Stable release. This commit here c07b410 has a list of CoreOS services.

Copy link
Copy Markdown
Contributor Author

@krnowak krnowak Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So network-online.target systemd-networkd-wait-online.service is not necessary I think, because there is a comment in systemd-networkd.service which we enable:

# We want to enable systemd-networkd-wait-online.service whenever this service
# is enabled. systemd-networkd-wait-online.service has
# WantedBy=network-online.target, so enabling it only has an effect if
# network-online.target itself is enabled or pulled in by some other unit.
Also=systemd-networkd-wait-online.service

Not sure about sockets.target systemd-networkd.socket - systemd-networkd.socket is pulled in by systemd-networkd.service also with the Also= option. So I guess it's not necessary anymore too.

Copy link
Copy Markdown
Contributor

@pothos pothos Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked and the Also= is not enough: after sudo systemctl status network-online.target I saw that systemd-networkd-wait-online.service is inactive while on 2512.2.0 it is active afterwards.

Copy link
Copy Markdown
Contributor

@pothos pothos Sep 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same situation for systemd-networkd.socket which gets activated on 2512.2.0 but not on 2605.5.0

Copy link
Copy Markdown
Contributor Author

@krnowak krnowak Sep 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added those, but I don't see any change, maybe it's something to investigate later:

systemd-networkd-wait-online.service:

core@localhost ~ $ systemctl status systemd-networkd-wait-online.service
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:systemd-networkd-wait-online.service(8)

systemd-networkd.socket:

core@localhost ~ $ systemctl status systemd-networkd.socket
● systemd-networkd.socket - Network Service Netlink Socket
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.socket; disabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-09-26 13:57:07 UTC; 7min ago
   Triggers: ● systemd-networkd.service
       Docs: man:systemd-networkd.service(8)
             man:rtnetlink(7)
     Listen: route 1361 (Netlink)
     CGroup: /system.slice/systemd-networkd.socket

systemd-networkd.service:

core@localhost ~ $ systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-09-26 13:57:09 UTC; 7min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
   Main PID: 729 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 1119)
     Memory: 2.4M
     CGroup: /system.slice/systemd-networkd.service
             └─729 /usr/lib/systemd/systemd-networkd

Sep 26 13:57:09 localhost systemd[1]: Starting Network Service...
Sep 26 13:57:09 localhost systemd-networkd[729]: Enumeration completed
Sep 26 13:57:09 localhost systemd[1]: Started Network Service.
Sep 26 13:57:09 localhost systemd-networkd[729]: eth0: IPv6 successfully enabled
Sep 26 13:57:09 localhost systemd-networkd[729]: eth0: Link UP
Sep 26 13:57:09 localhost systemd-networkd[729]: eth0: Gained carrier
Sep 26 13:57:09 localhost systemd-networkd[729]: eth0: DHCPv4 address 10.0.2.15/24 via 10.0.2.2
Sep 26 13:57:09 localhost systemd-networkd[729]: eth0: Unable to shorten overlong DHCP hostname 'flatcar_production_qemu-2632-0-0', ignoring: Numerical argum>
Sep 26 13:57:11 localhost systemd-networkd[729]: eth0: Gained IPv6LL

Copy link
Copy Markdown
Contributor

@pothos pothos Sep 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tried pulling the target in before with start network-online.target or sockets.target?

Copy link
Copy Markdown
Contributor

@pothos pothos Sep 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway thanks, also for making the situation much more clear now than it was before.

pothos
pothos reviewed Sep 25, 2020
View reviewed changes
margamanterola
margamanterola approved these changes Sep 25, 2020
View reviewed changes
Copy link
Copy Markdown
Contributor

@margamanterola margamanterola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me as is. We can re-iterate to make it better, but I'd like for this to land in Monday's patch release.

@krnowak
sys-apps/systemd: Enable remote-fs.target too.
98282a0 
Since v242, this unit is not enabled by default. Currently the
recommended way of initial enablement of the important units is
through `systemctl preset-all` with the preset file from systemd. We
don't want to do it, because this action creates symlinks in /etc, so
we enable those services ourselves by putting the symlinks in /lib.
@krnowak
sys-apps/systemd: Try harder at not enabling services through /etc
a649297 
At installation time, we usually want to enable services through
/lib. This change will stop making the installation to put symlinks
for getty in /etc, since we already do it in /lib.
@krnowak
sys-apps/systemd: Enable more services from upstream's preset
2ca1d6b 
This more or less mimics systemctl preset-all, but with enabling the
services in /usr, not in /etc, as /etc is not autoupdated.
@krnowak
sys-apps/systemd: Drop the handling of ENABLED_UNITS
e822b58 
We are installing systemd from scratch in the image, so there are no
previously enabled units to enable or reenable after
installation. Also, this code would enable the services in /etc, which
we don't want, because /etc is not autoupdated, so the enabled
services could end up still being disabled after the update.
@krnowak
sys-apps/systemd: Make a comment more clear
6ed07ea
@krnowak krnowak force-pushed the krnowak/fix-remote-fs branch from 6a6a569 to 6ed07ea Compare September 25, 2020 18:39
@krnowak
sys-apps/systemd: Enable more services
47cf4eb 
These normally would be pulled by systemdctl enable when enabling
systemd-networkd.service, because they are used in Also= options. In
such case, we need to pull them ourselves, so they can be enabled in
/usr, not in /etc.
@krnowak
Copy link
Copy Markdown
Contributor Author

krnowak commented Sep 26, 2020

Tested the PR with following ignition config:

{
  "ignition": {
    "config": {},
    "security": {
      "tls": {}
    },
    "timeouts": {},
    "version": "2.3.0"
  },
  "networkd": {},
  "passwd": {},
  "storage": {},
  "systemd": {
    "units": [
      {
        "contents": "[Unit]\nBefore=remote-fs.target\n[Service]\nType=oneshot\nRemainAfterExit=yes\nExecStart=/bin/echo ajwaj!\n[Install]\nWantedBy=remote-fs.target\n",
        "enable": true,
        "name": "my-testing-unit.service"
      }
    ]
  }
}

status of remote-fs.target:

core@localhost ~ $ systemctl status remote-fs.target
● remote-fs.target - Remote File Systems
     Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; vendor preset: disabled)
     Active: active since Sat 2020-09-26 13:57:10 UTC; 3min 48s ago
       Docs: man:systemd.special(7)

Sep 26 13:57:10 localhost systemd[1]: Reached target Remote File Systems.

status of my testing unit:

core@localhost ~ $ systemctl status my-testing-unit.service
● my-testing-unit.service
     Loaded: loaded (/etc/systemd/system/my-testing-unit.service; enabled; vendor preset: enabled)
     Active: active (exited) since Sat 2020-09-26 13:57:10 UTC; 17s ago
    Process: 805 ExecStart=/bin/echo ajwaj! (code=exited, status=0/SUCCESS)
   Main PID: 805 (code=exited, status=0/SUCCESS)

Sep 26 13:57:10 localhost systemd[1]: Starting my-testing-unit.service...
Sep 26 13:57:10 localhost echo[805]: ajwaj!
Sep 26 13:57:10 localhost systemd[1]: Finished my-testing-unit.service.

contents of /etc/systemd/system:

core@localhost ~ $ ls -laR /etc/systemd/system
/etc/systemd/system:
total 28
drwxr-xr-x. 3 root root 4096 Sep 26 13:57 .
drwxr-xr-x. 6 root root 4096 Sep 26 13:57 ..
-rw-r--r--. 1 root root  137 Sep 26 13:57 my-testing-unit.service
drwxr-xr-x. 2 root root 4096 Sep 26 13:57 remote-fs.target.wants

/etc/systemd/system/remote-fs.target.wants:
total 20
drwxr-xr-x. 2 root root 4096 Sep 26 13:57 .
drwxr-xr-x. 3 root root 4096 Sep 26 13:57 ..
lrwxrwxrwx. 1 root root   43 Sep 26 13:57 my-testing-unit.service -> /etc/systemd/system/my-testing-unit.service

remote-fs in /usr/lib/systemd/system:

core@localhost ~ $ find /usr/lib/systemd/system | grep remote-fs
/usr/lib/systemd/system/remote-fs-pre.target
/usr/lib/systemd/system/multi-user.target.wants/remote-fs.target
/usr/lib/systemd/system/remote-fs.target.wants
/usr/lib/systemd/system/remote-fs.target.wants/var-lib-machines.mount
/usr/lib/systemd/system/remote-fs.target

Will merge and cherry-pick to other branches.

@krnowak krnowak merged commit cac281e into main Sep 26, 2020
This was referenced Sep 26, 2020
Merged
Merged
@krnowak krnowak deleted the krnowak/fix-remote-fs branch September 26, 2020 14:13
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

2 more reviewers

@pothos pothos pothos left review comments

@margamanterola margamanterola margamanterola approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

remote-fs.target not active when upgrading from older systemd versions

3 participants

@krnowak @pothos @margamanterola