"logs" command is supported only for "json-file" logging driver (got: journald)

[Brad Fitzpatrick]

I'm no longer able to run "docker logs <CONTAINER>" on CoreOS (alpha).

Is this a known regression?

This broke part of the Go build coordinator (http://farmer.golang.org/ which runs builds for https://build.golang.org/), because it depends on being able to inspect logs for a process running in Docker:

e.g.

farmer bradfitz # docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES

550acb5611df        go-watcher-world    "/usr/local/bin/watch"   7 minutes ago       Up 7 minutes                            tender_bartik

farmer bradfitz # docker logs 550acb5611df

"logs" command is supported only for "json-file" logging driver (got: journald)

[Seán C. McCord]

I would call that a "yay", then, if CoreOS is using journald for docker logs by default, now.  Those JSON logfiles have been a thorn in my side for far too long.  Of course, notice would probably be a good idea... as well as how the container names are mapped to journald names (assuming they are not unit-assigned).

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Seán C McCord

CyCore Systems, Inc

+1 888 240 0308

[Brad Fitzpatrick]

It appears it's also now using journald on CoreOS stable (808.0.0).

I'm all for journald, but an interface changed on me. Regardless of how they're stored, shouldn't the "docker logs $CONTAINER" command still work, mapping to whatever backend commands are required to get the logs back?

[Seán C. McCord]

808.0.0 is Alpha right now, not stable.  You are surely correct, though,  `docker logs` ought to work... but that appears to be a Docker limitation.

[Brad Fitzpatrick]

Oh, I switched the channel in my cloud-config but forgot to wipe the disk before I recreated the GCE instance.

CoreOS now says this on boot:

Connected, host fingerprint: ssh-rsa 2048 BD:4E:01:21:B1:A9:8B:5D:28:49:0E:F6:4D:B5:F1:21

Last login: Fri Sep 18 20:17:57 2015 from 74.125.72.49

CoreOS stable (808.0.0)

Update Strategy: No Reboots

Failed Units: 1

  locksmithd.service

bradfitz@farmer ~ $ 

Note that it calls it both stable and 808.0.0.

I'll recreate with stable and wiping the disk.

[Alex Crawford]

On 09/18, Brad Fitzpatrick wrote:
> Is this a known regression?

Yes, https://github.com/coreos/bugs/issues/483.

-Alex

[Alex Crawford]

On 09/18, Brad Fitzpatrick wrote:

> I'm all for journald, but an interface changed on me. Regardless of how
> they're stored, shouldn't the "docker logs $CONTAINER" command still work,
> mapping to whatever backend commands are required to get the logs back?

Yes, `docker log` should work. I'll have to dig into why a basic
configuration change can break core functionality like this. It will be
fixed in the next Alpha image though. Sorry about the regression.

-Alex

[Brad Fitzpatrick]

Thanks! I'm now watching https://github.com/coreos/bugs/issues/483 

[David Anderson]

On Fri, Sep 18, 2015 at 1:36 PM, Brad Fitzpatrick <br...@danga.com> wrote:

Oh, I switched the channel in my cloud-config but forgot to wipe the disk before I recreated the GCE instance.

CoreOS now says this on boot:

Connected, host fingerprint: ssh-rsa 2048 BD:4E:01:21:B1:A9:8B:5D:28:49:0E:F6:4D:B5:F1:21

Last login: Fri Sep 18 20:17:57 2015 from 74.125.72.49

CoreOS stable (808.0.0)

Update Strategy: No Reboots

Failed Units: 1

  locksmithd.service

bradfitz@farmer ~ $ 

Note that it calls it both stable and 808.0.0.

FWIW, this is expected: updating can only roll the version number forwards, so if you switch release tracks, you'll only start updating again when that release track has a version >$current_version. So, in practice, downgrading release tracks means you need to reimage.

- Dave