[lxc-users] about: Service fails to start due PID checking

Jimmy Thrasibule jimmy.thrasibule at gmail.com
Thu Jul 10 09:39:12 UTC 2014


Hi Guido,

> that's just a bad-styled init script because the assumption of "one PID" will fail in every context like Container virtualization Or, iff you even like to run two instances of such an program (using disjunctive resources by configuration). Using best practices, an init script will use an "PID-file" and will have the facility to "name" instances -- at least to distinguish this PID-file.
>
> There are other "bad-styled" packages. As I remember, syslog-ng (still?) have to be started on the host before other instances in the containers -- because it has a build-in mechanism against double-starting based on the same assumption. From this, you get into trouble if you need to restart it on the host for some reason.

I understand the issue however hiding the containers processes can
still be useful in some cases. We can already hide PIDs [1] from
users. Extending this to cgroups would be a nice to have.


> BTW: Do you know about the SSMTP package? This is an even more simple "Nullmailer" with offers not even queuing but will directly relay local mail to an mailhub. Because this is synchronous, there is not daemon required after all. If you may renounce the safety net of a local mail queue, this is much more simple because all you need to configure is the relay (and the local host name if not FQDN) and there's even an "alias" feature to forward mail for local uses to arbitrary email destinations, e.g to relay container foo's root email to foo at yourdomain. I'm using this in our enterprise setup for the Containers and even for the Hosts because here because there is one central internal queuing mailhub service available.

I know about sSMTP but I don't like the idea of direct mailing. Since
my mail server is not in the local network, I prefer to keep it safe
and have a mail queue just in case.


[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201


Jimmy


More information about the lxc-users mailing list