[systemd-devel] Provide INIT_VERSION?

Gustavo Sverzut Barbieri barbieri at profusion.mobi
Mon Sep 13 10:52:11 PDT 2010


On Mon, Sep 13, 2010 at 2:14 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 08.09.10 20:14, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:
>
>>
>> On Wed, Sep 8, 2010 at 7:16 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>> > On Wed, 08.09.10 11:24, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:
>> >
>> >> Hi all,
>> >>
>> >> Seems that sysvinit provides INIT_VERSION=sysvinit-1234 to its spawned
>> >> processes and tools like /sbin/halt check for it to just then check
>> >> for $RUNLEVEL so I wonder if we should provide this in systemd
>> >> automatically or I should change my .service units to provide them
>> >> with Environment=INIT_VERSION=sysvinit-1234
>> >
>> > I think the latter is nicer. After all we aren't sysvinit, so I'd prefer
>> > not to claim we were in the C sources. Also note that at least in the
>> > Fedora shutdown scripts we already set RUNLEVEL=0 via the Environment=
>> > option, so if INIT_VERSION is necessary it probably makes sense to place
>> > it in Environment= too.
>>
>> Yeah, I have those in my units, but it will suck as we'll have to do
>> replacement of systemd-$PACKAGE_VERSION.... or just stick some random
>> variable there, as sysvinit just check for variable existence but not
>> actual value.
>>
>> Anyway, maybe it's better to just ignore it and go straight with
>> systemd-native actions. Would you mind sharing your ideas about them?
>> Maybe I can help there as well.
>
> I figure you are aware that symlinking /sbin/reboot and friends to
> /bin/systemctl gives you systemd native implementation of these tools?

I was not aware... maybe because I still have sysvinit tools and they
are the ones there.

> Our rough plan for the long run for the implementaiton of late shutdown
> is to provide /lib/systemd/systemd-halt or so which will be exec'ed by
> PID1 in the end. This binary will then kill all remaining processes,
> unmount all fs, mount remaining fs r/o and then shutdown or kexec.
>
> The approach is kinda nice since we then avoid busy mmaps, and PID 1 is
> the first and last process of the system.

This seems like a good approach, I'll try to come with a systemd-halt
whenever times allow :-)


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202


More information about the systemd-devel mailing list