Re: [ptxdist] systemd: Using second offline update service beside rc-once in PTXDIST

[Michael Olbrich <m.olbrich@pengutronix.de>]

On Tue, Jun 06, 2017 at 03:28:47PM +0000, Schenk, Gavin wrote:
> Hi Michael,
> 
> > >
> > > Thank you for the fast feedback, I will send a patch.
> > >
> > > Some Questions:
> > > Using readlink is ok? (additional dependency rc-once -> readlink ) Is
> > > there anything more lightweight?
> > 
> > Not that I know. Note: if you use 'readlink -f' then the busybox version
> > has a option for this, so maybe:
> > 
> > 	select BUSYBOX_FEATURE_READLINK_FOLLOW	if BUSYBOX_READLINK
> > 	select COREUTILS			if !BUSYBOX_READLINK
> > 	select COREUTILS_READLINK		if !BUSYBOX_READLINK
> > 
> Ok, done.
> 
> > > Do we need this stuff configurable?
> > 
> > No. But I think we should have a sanity check. To avoid getting stuck in
> > the system-update.target: A service that is part of system-update.target
> > and starts the rescue target. rc-once.service and your service should
> > both be sorted 'Before' that service. If no other service starts a
> > different target we automatically fall into the rescue target.
> > 
> Is "FailureAction=reboot" or "FailureAction=rescue.target" in service
> file sufficient here?

Actually, I noticed that system-update-cleanup.service is supposed to
handle this case. I'm currently unsure if 'remove the link and reboot' is
ok, of if I want to drop into the rescue target.

> I am not happy with my implementation today :-(. The main reason is, it does not cover my usecase where I want to do something:
>    * Once at first boot
>    * With UI on tty
>    * Without conflicting rc-once
> 
> For this usecase it seems to be enough to add a service to
> system-update.target.wants with "After=rc-once.service". This is not
> flawless, because the system continues booting after rc-once is done e.g.
> getty.target. It seems to be related to "systemctl daemon-reexec" in
> systemd-rc-once I am not sure. The handling of bbinit beside systemd and
> managing write protection in this scripts scares me. I am afraid to break
> stuff when doing changes here.

This stuff is a bit tricky. There are several things to consider:
- The rootfs may or may not be mounted read-only. The remount stuff
  basically makes sure the rootfs is writable and returns to the previous
  state when we're done
- The rc-once may modify the currently running executables and libraries.
  'exec "$0" ...' and daemon-reexec try to make sure the new versions are
  used before the rootfs is mounted read-only. Otherwise this may fail.
- Deleting /system-update + daemon-reexec (or daemon-reload) results in a
  new 'default.target'. This is then activated by 'systemctl default'.
- If mounting read-only fails, we reboot and run rc-once again. All scripts
  are done at this point so that's just some remounting. This is needed to
  make sure the journal is flushed and the filesystem is clean.
- If any rc-once script fails, we want to drop into the rescue target. This
  is already used for other fatal errors during startup, so it's a central
  place to handle a broken rootfs.

> I reverted my last commit where I added some recommendations of freedesktop.org:
>    * Requires=sysinit.target
>    * After=sysinit.target
> 
> The result was a broken system. I reverted this to your implementation
>    * After=local-fs.target
>    * Requires=local-fs.target
>    * Before=system-update-cleanup.service
>    * After=system-update.target
> 
> I will send my three small patches after this mail. It adds a bugfix
> (etc/rc-once.d -> /etc/rc-once.d) and the readlink check. I moved the
> deletion of /system-update into run_rc_once function. Not sure if you like
> this, I followed recommendation 2.

I'm not sure what you want to do in your service. What should happen once
it's done?
We could split out the 'systemctl default' into a
'system-update-done.service'. Then you could sort your service between
rc-once an this new service. Would that work for you?

Do we need to check the link target of /system-update with your current
requirements? Is there a use-case where your service should be started, but
not rc-once? If not, then I'd say we leave this as is for now.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de