[systemd-devel] Environment & EnvironmentFile in unit files

[Lucian Muresan]

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?


Regards,
Lucian