[SOLVED] Problems with systemd-update-utmp after systemd update

mrzeznicki · 2012-06-02 13:02:26

Hi all,
I noticed that systemd-update-utmp-runlevel.service has been failing since the last systemd update. My systemd is:

Repository     : core
Name           : systemd
Version        : 184-2
...

$ systemctl status systemd-update-utmp-runlevel.service
systemd-update-utmp-runlevel.service - Update UTMP about System Runlevel Changes
          Loaded: loaded (/usr/lib/systemd/system/systemd-update-utmp-runlevel.service; static)
          Active: failed (Result: exit-code) since Sat, 02 Jun 2012 13:55:40 +0200; 56min ago
            Docs: man:utmp(5)
        Main PID: 395 (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/systemd-update-utmp-runlevel.service

The exact cause of error is:

Jun 02 13:55:40 arch systemd-update-utmp[395]: Failed to write utmp record: No such file or directory
Jun 02 13:55:40 arch systemd[1]: systemd-update-utmp-runlevel.service: main process exited, code=exited, status=1

What's more, after this update I am not able to mount vmware hgfs shares. I've got following entry in my /etc/fstab (from arch's wiki)

#enable shared folders
.host:/                                        /mnt/hgfs       vmhgfs  defaults,ttl=5                  0       0

It worked just fine. After the update system boots into maintenance mode with the following message found in sysemd-journal:

arch mount[143]: Directory in share name must not be empty
arch mount[143]: Error: share name is invalid, aborting mount

After commenting hgfs mount entry out the system boots normally.
Thanks in advance.

EDIT:
Mounting hgfs shares manually works as expected

$: sudo mount /mnt/hgfs
Could not add entry to mtab, continuing

mtab:

..
.host:/ /mnt/hgfs vmhgfs rw,relatime 0 0

so this issue must be systemd related

Last edited by mrzeznicki (2012-06-07 15:18:05)

falconindy · 2012-06-02 14:42:09

You're probably missing a symlink from /var/run to /run. We need to fix this in core/filesystem, but its not a simple change because it requires user intervention.

I can't reproduce your problem with mount. Is that the real host? Does it really start with a '.' ?

Last edited by falconindy (2012-06-02 14:42:31)

mrzeznicki · 2012-06-02 16:16:42

falconindy wrote:

You're probably missing a symlink from /var/run to /run. We need to fix this in core/filesystem, but its not a simple change because it requires user intervention.

In fact I do, should I create it myself?

falconindy wrote:

I can't reproduce your problem with mount. Is that the real host? Does it really start with a '.' ?

Yes, I copied this directly from https://wiki.archlinux.org/index.php/In … systemd%29
My arch machine is a vmware guest, I forgot to mention
Thanks for your answer

falconindy · 2012-06-02 16:28:06

mrzeznicki wrote:

In fact I do, should I create it myself?

Sure. The symlink is needed.

mrzeznicki wrote:

Yes, I copied this directly from https://wiki.archlinux.org/index.php/In … systemd%29
My arch machine is a vmware guest, I forgot to mention
Thanks for your answer

Still can't reproduce this. libmount's parser does just fine with ".host" as a dummy entry in my /etc/hosts file mapped for an NFS share.

mrzeznicki · 2012-06-03 01:22:56

falconindy wrote:

Still can't reproduce this. libmount's parser does just fine with ".host" as a dummy entry in my /etc/hosts file mapped for an NFS share.

Yep, libmount is probably not a problem, I guess this error comes from vmware's hgfsmounter

static Bool
ParseShareName(const char *shareName,      // IN:  Share name to validate
               const char **shareNameHost, // OUT: Share name, host component
               const char **shareNameDir)  // OUT: Share name, dir component
{
   const char *colon, *dir;

   /* 1) Must be colon separated into host and dir. */
   colon = strchr(shareName, ':');
   if (colon == NULL) {
      printf("Share name must be in host:dir format\n");
      return FALSE;
   }

   /* 2) Dir must not be empty. */
   dir = colon + 1;
   if (*dir == '\0') {
      printf("Directory in share name must not be empty\n");
      return FALSE;
   }

   /* 3) Dir must start with forward slash. */
   if (*dir != '/') {
      printf("Directory in share name must be an absolute path\n");
      return FALSE;
   }

   /* 4) Host must be ".host". */
   if (strncmp(shareName, ".host:", 6) != 0) {
      printf("Host in share name must be \".host\"\n");
      return FALSE;
   }

   *shareNameHost = ".host";
   LOG("Host component of share name is \"%s\"\n", *shareNameHost);
   *shareNameDir = dir;
   LOG("Directory component of share name is \"%s\"\n", *shareNameDir);
   return TRUE;
}

I am just wondering why it worked before (and why manual mount works). Is there anything in systemd mount layer that consumes '/'?

falconindy · 2012-06-03 01:29:05

systemd calls /bin/mount for anything except the API filesystems.

ataraxia · 2012-06-03 01:53:40

You might look in /run/systemd/generator for a file mnt-hgfs.mount. Show us what's in that file, and it will tell us how systemd (or more specifically, the new systemd-fstab-generator) parsed that line. The What=, Where=, Type=, and Options= fields should hopefully reflect correctly what you have in fstab. If they don't, it's likely a systemd bug that should be reported upstream. You should be able to work around it in this case by copying that file to /etc/systemd/system and "fixing" it, though I haven't tested this.

falconindy · 2012-06-03 02:12:39

Uggh, I forgot about that new generator... It does appear to be problematic...

<snip>
ExecMount={ path=/bin/mount ; argv[]=/bin/mount .host: /mnt -t nfs4 -o defaults,ro ; ignore_errors=no ; start_time=[Sat, 02 Jun 2012 22:07:32 -0400] ; stop_time=[Sat, 02 Jun 2012 22:07:32 -0400] ; pid=241 ; code=exited ; status=0 }

And I'm highly suspicious of a function called 'path_kill_slashes' that's called on the source...

Last edited by falconindy (2012-06-04 12:47:01)

falconindy · 2012-06-03 02:18:47

http://lists.freedesktop.org/archives/s … 05343.html

We'll see what upstream has to say...

mrzeznicki · 2012-06-03 14:56:08

That's it. I moved contents of /var/run to /run, removed /var/run and symlinked /var/run -> /run (I also did the same for /var/lock -> /run/lock). No more errors from systemd-update-utmp-runlevel. Everything seems to be working smoothly. Thanks.
Now, I assume that your analysis discovered that hgfs mount error relates to buggy upstream, right? Thanks for taking care of this, let's wait for a patch.

falconindy · 2012-06-04 13:27:05

Partially fixed: http://cgit.freedesktop.org/systemd/sys … 8431fd71fa
Actually fixed: http://cgit.freedesktop.org/systemd/sys … be0e83f1f7

edit: and fixed in testing with 184-3.

Last edited by falconindy (2012-06-04 14:02:47)

mrzeznicki · 2012-06-07 14:27:20

After updating systemd & co. to 185-1 problem indeed vanished. Thank you

Arch Linux

#1 2012-06-02 13:02:26

[SOLVED] Problems with systemd-update-utmp after systemd update

#2 2012-06-02 14:42:09

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#3 2012-06-02 16:16:42

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#4 2012-06-02 16:28:06

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#5 2012-06-03 01:22:56

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#6 2012-06-03 01:29:05

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#7 2012-06-03 01:53:40

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#8 2012-06-03 02:12:39

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#9 2012-06-03 02:18:47

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#10 2012-06-03 14:56:08

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#11 2012-06-04 13:27:05

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

#12 2012-06-07 14:27:20

Re: [SOLVED] Problems with systemd-update-utmp after systemd update

Board footer