[systemd-devel] Environment & EnvironmentFile in unit files

[Gustavo Sverzut Barbieri]

On Thu, Jan 27, 2011 at 12:32 PM, Lucian Muresan
<lucianm at users.sourceforge.net> wrote:
> On 27.01.2011 14:31, Gustavo Sverzut Barbieri wrote:
>> On Thu, Jan 27, 2011 at 8:10 AM, Lucian Muresan
>
> [...]
>
>> I'll let  the final decision to Lennart and Kay, the maintainers, but
>> from what I see and agree the idea is to avoid such crap completely.
>>
>> 1. these ExecPreStart are completely non-sense. These should be in
>> lircd if it really needs it. Send them the patches to fix it.
>> Meanwhile just make this a single binary that does such work, but
>> consider it a temporary remedy.
>
> Well, I'm just a user who wants to get his things up and running quickly
> atm, I do not really have the time to analyze the whole LIRC design in
> order to write useful patches (at least to not lose time writing them
> and end up called them "crap" by upstream, that should be something
> between them and systemd devs if they want their software supported, and
> possibly distributors). Of course, users might raise their attention on
> the issues...
>
>> 2. these non-daemon configuration files should be removed. It causes
>> no good other than stupid fragmentation among distributions (some in
>> /etc/conf.d, others in /etc/sysconfig, ...). The way to go is the
>> daemon itself to have its configuration file and read it directly.
>
> I'm not proposing the place where Gentoo stores these config files for
> every distribution, it's just my current approach to keep common
> settings as long as I don't wipe OpenRC from my box yet). The same
> applies here, if upstream does that, I will use it that way...
>
>> 3. do not use forking. I consider it a temporary solution, but the way
>> to go is to make the daemons do not fork and let systemd babysit them.
>> If lircd does not support something like that, send them the patches.
>
> Well, I tried that with the 2 services lircd and irexec but the latter
> fails loading successfully, maybe it tries to connect to the former too
> quickly when both in non-deamon mode. So yes, they both support running
> in the foreground, but something goes wrong and again, I'm not the one
> to try fixing it.
>
>> 4. last but not least these things that rely on /dev should be
>> activated by udev whenever it notifies the device is presence.
>
> In my case, /dev/lircd (btw, I wrote it  wrong in my first samples,
> after finding out that I cannot use variables) is just a symlink to a
> pipe, needed only for compatibility reasons with older software
> expecting that device, nevertheless, someone with another remote control
> may have to use a kernel module which actually creates that device file
> itself on loading, as you can see, you cannot treat programs so
> simplistic. It may be a broken design, I'm not the one to evaluate that
> now, but atm your udev activation proposal may also only work for some
> configurations...
>
> What I did was to try writing my unit files with as less extra stuff as
> possible, but where I needed extra stuff, I just did what the old Openrc
> scripts do on gentoo, in order to get things done for me at least.
>
>
> So passing a configurable user to the daemon should also be solved by
> upstream?

Yes.

Until then, I understand your point and you want things running. But
the design of systemd is not changing to match it. I'd recommend that
instead you create your binaries  like lircd-systemd-launcher.sh that
does that mess there and then "exec /usr/sbin/lircd $YOUR_OPTS" in a
non-forking way. Systemd will babysit them nicely, once the upstream
is fixed, then you just replace your Exec= line.  You can do this by
copying and modifying openrc's script, just get ride of the
#!/sbin/runscript and the provided functions, of course you wont need
"depend()" anymore as well.

As for the non-forking mode, if one tries to communicate with the
other you need to make them depend on each other, see the unit manpage
on the multitude of ways to specify that.

You can also run the binary manually with strace and check if it fails
to find some socket or so.


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