pid1: maybe add transient units that survive reboots in some form

[viraptor]

Is your feature request related to a problem? Please describe.
When creating transient timers, it seems it's impossible to schedule something to happen at the next boot time. Usually when you run:

systemd-run --on-boot=5m foobar

you're either just booting up and foobar is going to run in a moment, or you're on a system which was up for a while and foobar will run immediately, because it's past "5m after bootup".

What I mean though is "run it 5min after the next boot", which is roughly equivalent to creating a timer and not activating it until the next daemon-reload.

I was also hoping that --timer-property=Persistent=false would achieve what I want... but it doesn't.

Possibly related to #12921

Describe the solution you'd like
I'd like an option like --skip-current or --create-inactive which creates the timer but doesn't allow it to fire immediately.

Describe alternatives you've considered
I can do a similar thing by creating an explicit timer service and letting systemd load it on next boot. Having it in systemd-run would be nicer though.

[poettering]

transient units are purely transient, they are never persisted to disk.

[ossilator]

this would be very useful, indeed, in particular in conjunction with #8705.

note that currently there is an anomaly related to that: you can create a transient timer with --timer-property=Persistent=true, which will result in an entry in /var/lib/systemd/timers, which will become invalid after reboot.

also overlaps with issue #3234.

[DaanDeMeyer]

I was redirected here from #14245. A general way to have systemd-run persist units to /etc/systemd/system would be useful. This would likely have to be limited to the service mode of systemd-run and not the scope mode. For example, a simple --persist option to write systemd-run generated unit files to /etc/systemd/system would be perfect for my use cases. Is there anything different about transient units that prevents persisting them?

[poettering]

Duplicate of #10572

[ossilator]

ugh, that's a rather generous interpretation of "duplicate" ...