-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[systemd]: Add platform-init and role-config services; Deprecate rc.local #427
base: master
Are you sure you want to change the base?
Changes from all commits
fc31d83
be8116f
2296d8c
cfcacdb
4bd76f3
ca2d1c2
48b22a1
20bfd02
ecc4729
d4e52b8
f510a65
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
[Unit] | ||
Description=First boot platform initialization | ||
Before=updategraph.service | ||
ConditionPathExists=/host/platform/firsttime | ||
|
||
[Service] | ||
Type=oneshot | ||
ExecStartPre=/bin/echo "First boot detected. Initializing platform..." | ||
ExecStart=/usr/bin/platform-init.sh | ||
ExecStartPost=/bin/rm -f /host/platform/firsttime | ||
|
||
[Install] | ||
WantedBy=multi-user.target |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
#!/bin/bash | ||
# | ||
# platform-init.sh | ||
# | ||
# Script to perform tasks which configure platform upon first boot | ||
# To be run by platform-init.service if it detects first boot | ||
# | ||
|
||
PLATFORM=`sonic-cfggen -v platform` | ||
|
||
if [ -n $PLATFORM ]; then | ||
echo "SONiC platform: $PLATFORM" | ||
|
||
echo "Copying default minigraph for $PLATFORM to /etc/sonic/" | ||
cp /usr/share/sonic/device/$PLATFORM/minigraph.xml /etc/sonic/ | ||
|
||
if [ -d /host/platform/$PLATFORM ]; then | ||
echo "Installing platform-dependent packages for $PLATFORM..." | ||
dpkg -i /host/platform/$PLATFORM/*.deb | ||
fi | ||
else | ||
echo "SONiC platform unknown. Could not install platform-dependent packages." | ||
fi | ||
|
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
[Unit] | ||
Description=Role-specific configuration | ||
After=updategraph.service | ||
|
||
[Service] | ||
Type=oneshot | ||
ExecStart=/usr/bin/role-config.sh | ||
|
||
[Install] | ||
WantedBy=multi-user.target |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
#!/bin/bash | ||
# | ||
# role-config.sh | ||
# | ||
# Script to perform tasks which configure device based on its role as determined by its minigraph | ||
# To be run by role-config.service | ||
# | ||
|
||
# Disable DHCP relay service if device does not require it | ||
DHCP_RELAY_SERVICE_START_FILE=/etc/sonic/role/dhcp_relay | ||
DEVICE_ROLE=`sonic-cfggen -m /etc/sonic/minigraph.xml -v "minigraph_devices[minigraph_hostname]['type']"` | ||
|
||
if [ $DEVICE_ROLE == "ToRRouter" ]; then | ||
echo "Device requires DHCP relay service. Ensuring start file exists..." | ||
touch $DHCP_RELAY_SERVICE_START_FILE | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we do systemctl disable dhcp-relay.service instead of using additional files? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was my original intent because it's very clean, and I tested it first. Unfortunately, when systemd starts up, it loads all of the unit files into memory, so calling There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also feel using systemctl disable/enable is cleaner. can we by default disable those two service (teamd/dhcprelay) and only enabled them ondemand? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm afraid that @jleveque is right and using systemd enable/disable will require starting services manually or restarting device for changes to take effect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean disable them by default, and then if we need to enable it, we can do start first and enable for the next reboot. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then the question becomes "When do we start the role-specific services?" Doing what you describe (starting the services manually) defeats the dependency mechanism in systemd. The only safe solution would be to start these services last. How would we ensure this? Also, what if in the future we have dependencies between role-specific services? That would be nearly impossible to manage manually. Also, what happens if someone changes the minigraph, and role-specific services are no longer needed? We would have to do the inverse: stop an already-started service, which feels quite sloppy to me. |
||
else | ||
echo "Device does not require DHCP relay service. Deleting start file..." | ||
rm -f $DHCP_RELAY_SERVICE_START_FILE | ||
fi | ||
|
||
|
||
# Disable teamd service if device does not require it | ||
TEAMD_SERVICE_START_FILE=/etc/sonic/role/teamd | ||
NUM_PORTCHANNELS=`sonic-cfggen -m /etc/sonic/minigraph.xml -v "minigraph_portchannels.keys() | count"` | ||
|
||
if [ $NUM_PORTCHANNELS -gt 0 ]; then | ||
echo "Device requires teamd service. Ensuring start file exists..." | ||
touch $TEAMD_SERVICE_START_FILE | ||
else | ||
echo "Device does not require teamd service. Deleting start file..." | ||
rm -f $TEAMD_SERVICE_START_FILE | ||
fi | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to disable the service, instead of manipulating a file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it would be possible to disable the service after it completes. I hadn't considered the possibility, as the 'firsttime' file method is currently used, and it just seems a little strange to have a service disable itself.
Anyone else have an opinion on this?