(In reply to Jiri Slaby from comment #8) > Then, it uses the read end for polling: > r = sd_event_add_io(UNIT(a)->manager->event, &a->pipe_event_source, > p[0], EPOLLIN, automount_dispatch_io, a); It basically adds a new event EPOLLIN associated to the read end of the pipe to the list of events we're interested in. EPOLLHUP is also implicitly added BTW. > If I am not mistaken, this is exactly the problem as automount_dispatch_io > checks revents and prints the error if it is not POLLIN: > log_unit_error(UNIT(a), "Got invalid poll event %"PRIu32" on pipe > (fd=%d)", events, fd); > > Obviously, one cannot poll read end of the pipe and expect to receive POLLIN > in this situation. POLLHUP is what it obviously and correctly gets. Why not ? EPOLLIN means that the kernel sent some data in the pipe and the data are ready to be read on the other end of the pipe. That's what is happening when the kernel informs systemd that it should proceed by mounting the fs. OTOH EPOLLHUP is supposed to mean (in my understanding) that the kernel closed the write end of the pipe for some reasons. Apparently it does that in your case only since recently after a resume. This new behavior is not expected by systemd and it would be interesting to understand why the kernel does that now. Or maybe I just missed your point ;)