Re: [systemd-devel] My experience with MySQL and systemctl

2017-04-19 Thread Samuel Williams
Lennart, it's absolutely possible this is the case, and as I stated
originally, I'm not sure where fault lies, but just that some issues
happened. I agree, perhaps MySQL/MariaDB should output one line for
each progress step.

On 20 April 2017 at 04:41, Lennart Poettering <lenn...@poettering.net> wrote:
> On Wed, 19.04.17 15:25, Samuel Williams (space.ship.travel...@gmail.com) 
> wrote:
>
>> I am using MariaDB - and the .service file launches mysqld directly -
>> it doesn't use mysqld_safe
>>
>> Here is the basic config, from Arch linux package:
>>
>> -- mariadb.service
>> ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
>> $_WSREP_START_POSITION
>> ExecStartPost=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
>> KillMode=process
>> KillSignal=SIGTERM
>> SendSIGKILL=no
>> Restart=on-abort
>> RestartSec=5s
>>
>> I checked correctly and the log output did appear stopped. Even though
>> the process was still running. The log output of mysqld during
>> recovery is only single progress counter without any newline
>> character.. perhaps this was part of the problem?
>
> So mysql is not logging via syslog() but via stdout/stderr? If so:
> journald expects \n as log record separator, and if you never send any
> then the record will never be generated (except when an EOF is read).
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] My experience with MySQL and systemctl

2017-04-18 Thread Samuel Williams
I am using MariaDB - and the .service file launches mysqld directly -
it doesn't use mysqld_safe

Here is the basic config, from Arch linux package:

-- mariadb.service
ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
$_WSREP_START_POSITION
ExecStartPost=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
KillMode=process
KillSignal=SIGTERM
SendSIGKILL=no
Restart=on-abort
RestartSec=5s

I checked correctly and the log output did appear stopped. Even though
the process was still running. The log output of mysqld during
recovery is only single progress counter without any newline
character.. perhaps this was part of the problem?

I'm happy to have started a useful discussion, and I'm happy to
provide any feedback. I think, ideally, the service should be marked
as "starting up" but not "running" until recovery is complete. That's
because it won't accept connections until the table is fixed. However,
while in this starting up state, during table recovery, if something
bad happens, service may crash.

I think ideally, if the service is taking a long time to start up, the
log output should be written directly to the person who invoked
systemctl, so they can see what is going on.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] My experience with MySQL and systemctl

2017-04-18 Thread Samuel Williams
Also, it was me sending SIGKILL, not systemctl. systemctl sent SIGTERM
and then finished. But process is still running, so system ended up in
weird state.

On 19 April 2017 at 15:25, Samuel Williams
<space.ship.travel...@gmail.com> wrote:
> I am using MariaDB - and the .service file launches mysqld directly -
> it doesn't use mysqld_safe
>
> Here is the basic config, from Arch linux package:
>
> -- mariadb.service
> ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
> $_WSREP_START_POSITION
> ExecStartPost=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
> KillMode=process
> KillSignal=SIGTERM
> SendSIGKILL=no
> Restart=on-abort
> RestartSec=5s
>
> I checked correctly and the log output did appear stopped. Even though
> the process was still running. The log output of mysqld during
> recovery is only single progress counter without any newline
> character.. perhaps this was part of the problem?
>
> I'm happy to have started a useful discussion, and I'm happy to
> provide any feedback. I think, ideally, the service should be marked
> as "starting up" but not "running" until recovery is complete. That's
> because it won't accept connections until the table is fixed. However,
> while in this starting up state, during table recovery, if something
> bad happens, service may crash.
>
> I think ideally, if the service is taking a long time to start up, the
> log output should be written directly to the person who invoked
> systemctl, so they can see what is going on.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] My experience with MySQL and systemctl

2017-04-10 Thread Samuel Williams
I had an accident last night. I tried to delete a lot of rows from a
production database in one transaction. I killed the transaction, and
I didn't realise it was still rolling back an hour later when I tried
to reboot the system for updates.

I might be wrong about exactly who is doing what, but I'll do my best
to explain what happened, and then give a few notes about how I think
the process could be improved. I don't specifically know if it's
systemctl or the service file, or mysqld causing the issues.

systemctl tried to shutdown mysqld, but due to the rollback, it
wouldn't exit with anything less than kill -9. So, systemctl entered
the failed state, however, in addition to that, it appears it closed
the log output of the mysqld process so I couldn't see any of the
output from the daemon.

Eventually, after checking all our backups, I decided to issue kill -9
to mysqld. I then decided to try restarting the daemon using
systemctl. It did start up, the log output showed the crash recovery
procedure, but because it entered into the rollback recovery,
systemctl never considered that the process had finished starting up,
and then tried to kill it again, which failed (only kill -9 would work
in this case). Again, log output was closed.

I issued kill -9 again, and started up the process manually `sudo -u
mysql mysqld` and let it go through the entire recovery process, and
then rebooted the system. Normalcy restored.

I think that the following things could be investigated/improved:

- Log output shouldn't be closed if the daemon can't be killed. I'm
not sure who is doing this - perhaps it's mysqld, or perhaps it's the
service file, or perhaps its systemctl?

- If a daemon fails to start up, trying to kill it.. may not be the
best option. It's probably a matter of the systemctl service file
detecting that a rollback is in progress and accepting that as a valid
startup state, but I'm not really sure. In any case, I ended up having
to do this process manually.

Kind regards,
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Okay so after mucking around a bit more, I was wondering if the most
logical way to solve this problem would be to edit /etc/pam.d/sudo to
add pam_systemd.so - would this work? I tried it and couldn't get it
to do anything meaningful, but TBH PAM is not my area of expertise.

On 14 December 2016 at 15:36, Samuel Williams
<space.ship.travel...@gmail.com> wrote:
> Okay, so tried some more things.
>
> $ sudo su - http env
> This account is currently not available.
>
> That's because the user has nologin set as the shell.
>
> So, does that mean it's impossible to use systemctl --user ?
>
>
>
> On 14 December 2016 at 13:13, Samuel Williams
> <space.ship.travel...@gmail.com> wrote:
>> Its unfortunately common for popular software to have CVEs, it's a sign of
>> an overall healthy environment I think. In any case my original point still
>> stands, regarding formal verification. But that's not the main issue here so
>> let's not get sidetracked :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Okay, so tried some more things.

$ sudo su - http env
This account is currently not available.

That's because the user has nologin set as the shell.

So, does that mean it's impossible to use systemctl --user ?



On 14 December 2016 at 13:13, Samuel Williams
<space.ship.travel...@gmail.com> wrote:
> Its unfortunately common for popular software to have CVEs, it's a sign of
> an overall healthy environment I think. In any case my original point still
> stands, regarding formal verification. But that's not the main issue here so
> let's not get sidetracked :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Its unfortunately common for popular software to have CVEs, it's a sign of
an overall healthy environment I think. In any case my original point still
stands, regarding formal verification. But that's not the main issue here
so let's not get sidetracked :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
> Well, given I opened the PR, I'd hope the chance is very low -- at least, no 
> more than sudo.

Sudo verifies the configuration using a regular language. It doesn't
mean you can't shoot yourself in the foot, but it makes it pretty damn
hard. JavaScript on the other hand.. a logic bug or error in the code
might bork the entire system and since it's turing complete it's
impossible to test for this condition before it occurs. Which is why
sudo was designed the way it was.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
So, I was playing around with sudo and found the following:

% env | grep XDG
XDG_SESSION_ID=4
XDG_RUNTIME_DIR=/run/user/1000

% sudo -u http env | grep XDG
... nothing...


Found this: 
http://stackoverflow.com/questions/28809235/how-to-get-xdg-variables-with-sudo

Of course, using a login shell is not feasible:

% sudo -iu http env
-nologin: invalid option -- 'c'

That's a deliberate security consideration.

Ideas?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
> Putting aside the issue of having users link their own units into the system 
> configuration -- as pointed out else in this thread, that comes with a *lot* 
> of security issues -- you don't even need sudo or su to allow users to 
> control system units.

You are absolutely correct. The users have control to the software
that's being run on the system in any case, if they are malicious it's
game over. Nothing can prevent that. On production, the only user is
`ci` anyway. It could be that we run the foreman export task as this
user which has password-less sudo. It's not feasible to manage 20
independent passwords for 20 deployments. SSH keys are the best option
in my experience, but welcome any suggestions here.

What I'm more interested in doing is *protecting the http user so that
if someone, somehow, does manage to crack the web application, they
can't get root*.

Right now, that is possible by allowing sudo systemctl link or
equivalent which is why I'm here discussing the issue. We'd ideally
like to keep http, http everywhere (i.e. no obvious/deliberate ability
for privilege escalation).

The nice thing about sudo is that it is a general framework that is
well tested, well documented, and works everywhere... polkit, less so.
Even with the best of intentions, looking at how well people have
managed to script security features (e.g. look at the whole ethereum
contract fiasco), stuff in that PR makes me a bit worried. What's the
chance someone screws up a security rule? JavaScript is only a small
step up from PHP in terms of semantic rigour, so I'd be concerned
about that too.

As I said, ideally we'd be able to enforce this logic directly within
/etc/systemd/system/$user, but if that's not possible, `systemd
--user` is a close 2nd given what I've seen. We just need to figure
out how to make it work in a sudo environment (could necessitate a
change to /etc/sudoers which would be fine).

Thanks for your input.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Reindl, thanks for your continued help.

> what *exact* problem are you trying to solve - don#t come with the solution
> "doing that as systemd-unit" - explain the problem what you are trying to
> solve not the solution you think is good!

Okay, our website deployment process is something like this.

Developers (or ci) have a password-less (ssh key only) account on the
server (either production or development).

- They push code into a repository on the production server using git.
They are a member of the group of the .git directory (usually http),
the code is pushed as the website user/group so that all users can do
it without borking up the permissions on files.
- The git repository runs a post-receive hook as that user (e.g. "bob"
or "ci"). It performs several tasks as that user, but the primary
task, once the source code is checked out and updated, is to deploy
any changes.
- The way this works, is that `rake deploy` is run in the web
directory. This task does quite a bit of stuff, including updating
foreman tasks.
- Foreman can generate tasks in lots of different ways, but we prefer
systemd units. We essentially run `sudo systemctl stop
$website.target`, `foreman export ...` and then `sudo systemctl start
$website.target`.

Exact foreman command: sh("bundle", "exec", "foreman", "export",
"systemd", SYSTEMD_UNIT_PATH, "-a", DATABASE_NAME, "-u",
`whoami`.chomp!)

sudo is set up to allow developers to do pretty much anything without
a password, while the website user is locked down pretty tightly.
Ideally, we don't expose root via the ability to arbitrarily load
systemd tasks.

For me, the ideal solution would be something like a per-user global
systemd unit directory. In theory, systemd would run units in that
directory locked down to that specific user. But, being in the global
context, would allow tasks to depend on each other. If it was kept in
a separate directory, it would simplify deployment and changes.

The next best solution as far as I can see, is to use systemd --user.
But this has a number of downsides - firstly out of the box it doesn't
work with a sudo environment:

Logged in as a dev user:

% systemd-run --user sleep 10
Running as unit: run-r341b245b4e324a2fa9aec1c272d8abea.service

% sudo -u http !!
sudo -u http systemd-run --user sleep 10
Failed to create bus connection: No such file or directory

% su -c "sudo -u http systemd-run --user sleep 10" - http
Password:
su: Authentication failure

Secondly, I've got concerns about how reliable this is in terms of
tasks that need to start at boot, and might have dependencies on
system-level tasks. How does `loginctl enable-linger http` work and is
it reliable?

Thanks for any insight, ideas, or suggestions you might have to
improve this process.

Kind regards
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Reindl, I understand where you are coming from, but I'm not sure I
understand what the alternative you are proposing is, are you
suggesting I use su?

On 14 December 2016 at 10:45, Reindl Harald <h.rei...@thelounge.net> wrote:
>
>
> Am 13.12.2016 um 22:40 schrieb Samuel Williams:
>>
>> Reindl, thanks for your ideas.
>>
>> So, I log in as me "bob", but I want to run a task as http, e.g. sudo
>> -u http git checkout -f
>>
>> What do you propose as the alternative?
>
>
> "man su" - the environment is completly different
>
> it's also different between "su" and "su -"
>
> but how is *that* a systemd-unit job and what do you think to gain when you
> work all the time with sudo (in the worst case even without a password)
>
> P.S: get rid of reply-all, i donät need two copies of every list mail one
> responds to
>
>
>> On 14 December 2016 at 09:49, Reindl Harald <h.rei...@thelounge.net>
>> wrote:
>>>
>>>
>>>
>>> Am 13.12.2016 um 21:41 schrieb Samuel Williams:
>>>>
>>>>
>>>> I wanted to use systemd --user but had trouble getting it to run via
>>>> sudo- seemed like the environment wasn't getting set up correctly. Any
>>>> ideas?
>>>
>>>
>>> get rid of sudo and re-consider everything where you are using sudo/su
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Reindl, thanks for your ideas.

So, I log in as me "bob", but I want to run a task as http, e.g. sudo
-u http git checkout -f

What do you propose as the alternative?

On 14 December 2016 at 09:49, Reindl Harald <h.rei...@thelounge.net> wrote:
>
>
> Am 13.12.2016 um 21:41 schrieb Samuel Williams:
>>
>> I wanted to use systemd --user but had trouble getting it to run via
>> sudo- seemed like the environment wasn't getting set up correctly. Any
>> ideas?
>
>
> get rid of sudo and re-consider everything where you are using sudo/su
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
I wanted to use systemd --user but had trouble getting it to run via sudo-
seemed like the environment wasn't getting set up correctly. Any ideas?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
I will explore using link further. However, in some cases the
behaviour is hard to leverage.

I'm using foreman to generate systemd files. If I remove an existing
target, it will be hard to replicate this.. unless I trash everything
before re-linking everything. It's not a very elegant solution.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Before I got to bed. It seems like it would make the most sense for me
to be able to namespace unit files. e.g. make a directory such as
/etc/systemd/system/http and give that directory suitable permissions.
Then, it's simpler to blow away all targets/services in that directory
if I need to rewrite them. It would be nice if there was some way to
do this with systemd/systemctl. Another option would be to have a
config file allowing you to specify alternative directories.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Hmm, so my local units directory contains business_development.target
which contains

Wants=business_development-resque-worker-high-priority.target
business_development-resque-worker.target

But when using systemctl link, neither of these get installed
correctly (and no warning is given when running the
business_development.target).

Any ideas?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
Thanks Andrei, this is something I will explore. Will this work well
if I have targets which have multiple dependencies? i.e. can I just
link the top level target?

On 14 December 2016 at 01:36, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 3:23 PM, Samuel Williams
> <space.ship.travel...@gmail.com> wrote:
>> I'd like my http user to be able to install unit files and start/stop them.
>>
>> Starting and stopping them is fairly easy with a sudo rule..
>>
>> But adding them is a bit trickier. I could also use sudo but it seems
>> fairly specific.
>>
>> Is there some way to add a new directory, e.g.
>> /etc/systemd/system/http which has permissions specific for http user?
>>
>> I can install targets/services/etc into that directory and then use
>> sudo systemctl start/stop
>>
>> Thanks for any ideas or suggestions. Alternative ways to achieve the
>> same thing also welcome.
>>
>
> You can use "systemctl link /path/to/unit/file", this probably is more
> friendly for sudo pattern to match only specific /path/to/unit/
> directory.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Best way to limit per-user system-wide units

2016-12-13 Thread Samuel Williams
I'd like my http user to be able to install unit files and start/stop them.

Starting and stopping them is fairly easy with a sudo rule..

But adding them is a bit trickier. I could also use sudo but it seems
fairly specific.

Is there some way to add a new directory, e.g.
/etc/systemd/system/http which has permissions specific for http user?

I can install targets/services/etc into that directory and then use
sudo systemctl start/stop

Thanks for any ideas or suggestions. Alternative ways to achieve the
same thing also welcome.

Kind regards,
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] hostnamectl set-deployment

2016-12-05 Thread Samuel Williams
I want to use this field for a list of roles the server will be setup
with. It feels like a logical thing to do. But for some reason, the
field is very limited:

# hostnamectl set-deployment "roles:development roles:business"
Could not set property: Invalid deployment 'roles:development roles:business'

I can't seem to put in whitespace, underscores, etc. Why is it so limited?

Kind regards,
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment

2016-10-12 Thread Samuel Williams
I'm not sure if this belongs in machinectl, but it would be interesting to
explore some kind of deployment mechanism. e.g. machinectl deploy
local-container-name ssh://remote-server:container-name because I'm sure
this is going to be a really common use case, and there are enough details
(e.g. stopping and starting the remote machine) that it would be nice to
keep it easy for new users.

On 13 October 2016 at 02:10, Chris Bell <cwb...@narmos.org> wrote:

> On 2016-10-11 22:29, Samuel Williams wrote:
>
>>
>> For step 2, what would be the best practice. Rsync the local container
>> to the remote container?
>>
>>
> That's worked fine for me so far. Just to state the obvious: makes sure
> the container is stopped before using rsync.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How to deploy systemd-nspawn containers and use for deployment

2016-10-11 Thread Samuel Williams
Hello.

I've been thinking about how I could use systemd-nspawn containers.

Ideally, we have a local container which can then be pushed to one or more
VPS instances.

An example workflow might look like this:

- Step 1: On development box, update some software in a container and test.
It's okay.
- Step 2: Push the container to several VPSs, some procedure to minimise
downtime while updating.
- Step 3: ...
- Step 4: Profit.

For step 2, what would be the best practice. Rsync the local container to
the remote container?

Kind regards,
Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to log to journald using fifo?

2016-04-13 Thread Samuel Williams
I guess what I'm proposing is not a specific workaround but a way for
legacy software which can only log to a file to get it's data into
journald. There is plenty of software like that, unfortunately. It's a
pragmatic option.

In this specific case, I'm referring to Nginx in daemon mode, which closes
/dev/stderr as far as I can tell, and then spawns passenger, which can only
log to a file. There is no way to hook up passenger to /dev/stderr.

The proposed service allows anyone to set up a fifo for logging in this
situation, it's very trivial and easy to set up, but I suspect there is
more than just one person with this issue.

On 12 April 2016 at 02:21, Lennart Poettering <mzq...@0pointer.de> wrote:

> On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com)
> wrote:
>
> > Hello,
> >
> >
> > I've been trying to figure out the best way to support legacy
> applications
> > that don't support syslog for logging. The best we can do, I think, is to
> > use fifo and have another process read the fifo to journald.
>
> Note that on systemd everything logged out stdout or stderr ends up in
> the journal anyway. And you can specify /dev/stderr or /proc/self/fd/2
> as path referring to stderr on Linux generally, if you need.
>
> > Finally, if this is a good approach, is this method worth putting into
> > systemd/journald as a standard service? If so, how do I submit a PR or
> > where to begin?
>
> Specific work-arounds around other, unrelated pieces of software are
> not really what we we'd like to add to systemd directly. Sorry.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to log to journald using fifo?

2016-04-10 Thread Samuel Williams
I would like to write to /dev/stderr and tried that but it didn’t work. I think 
it’s something to do with the way it works internally (nginx + phusion 
passenger).

> On 11/04/2016, at 12:43 AM, Mantas Mikulėnas <graw...@gmail.com> wrote:
> 
> On Sun, Apr 10, 2016 at 1:57 PM, Samuel Williams 
> <space.ship.travel...@gmail.com <mailto:space.ship.travel...@gmail.com>> 
> wrote:
> Hello,
> 
> I've been trying to figure out the best way to support legacy applications 
> that don't support syslog for logging. The best we can do, I think, is to use 
> fifo and have another process read the fifo to journald.
> 
> I made the following unit journald-fifo@.service
> 
> [Unit]
> Description=A fifo for logging to journald
> AssertPathExists=/var/log/%i.fifo
> 
> [Service]
> Type=simple
> ExecStart=/bin/sh -c 'while true; do systemd-cat -t %i < /var/log/%i.fifo; 
> done'
> Nice=5
> 
> [Install]
> WantedBy=multi-user.target
> 
> I was wondering is this a good approach? Is there a better way? (of course, 
> we'd like to fix the original software to work better).
> 
> If the software can log to stdout/stderr, just use that. If not, make it 
> write logs to "/dev/stderr". Either way, systemd will log service stdout 
> automatically.
> 
> -- 
> Mantas Mikulėnas <graw...@gmail.com <mailto:graw...@gmail.com>>

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How to log to journald using fifo?

2016-04-10 Thread Samuel Williams
Hello,


I've been trying to figure out the best way to support legacy applications
that don't support syslog for logging. The best we can do, I think, is to
use fifo and have another process read the fifo to journald.


I made the following unit journald-fifo@.service


[Unit]

Description=A fifo for logging to journald

AssertPathExists=/var/log/%i.fifo


[Service]

Type=simple

ExecStart=/bin/sh -c 'while true; do systemd-cat -t %i < /var/log/%i.fifo;
done'

Nice=5


[Install]

WantedBy=multi-user.target

I was wondering is this a good approach? Is there a better way? (of course,
we'd like to fix the original software to work better).


Finally, if this is a good approach, is this method worth putting into
systemd/journald as a standard service? If so, how do I submit a PR or
where to begin?


Kind regards,

Samuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel