{"action":"closed","issue":{"url":"https://api.github.com/repos/systemd/systemd/issues/4787","repository_url":"https://api.github.com/repos/systemd/systemd","labels_url":"https://api.github.com/repos/systemd/systemd/issues/4787/labels{/name}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/4787/comments","events_url":"https://api.github.com/repos/systemd/systemd/issues/4787/events","html_url":"https://github.com/systemd/systemd/issues/4787","id":192899391,"number":4787,"title":"\"Failed\" service unit propagates start dependency","user":{"login":"thx1111","id":8881258,"avatar_url":"https://avatars.githubusercontent.com/u/8881258?v=3","gravatar_id":"","url":"https://api.github.com/users/thx1111","html_url":"https://github.com/thx1111","followers_url":"https://api.github.com/users/thx1111/followers","following_url":"https://api.github.com/users/thx1111/following{/other_user}","gists_url":"https://api.github.com/users/thx1111/gists{/gist_id}","starred_url":"https://api.github.com/users/thx1111/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thx1111/subscriptions","organizations_url":"https://api.github.com/users/thx1111/orgs","repos_url":"https://api.github.com/users/thx1111/repos","events_url":"https://api.github.com/users/thx1111/events{/privacy}","received_events_url":"https://api.github.com/users/thx1111/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-12-01T16:43:57Z","updated_at":"2016-12-01T22:54:56Z","closed_at":"2016-12-01T22:54:56Z","body":"  - [ ] Bug report\r\n  - [ ] Request for enhancement (RFE)\r\n\r\n> systemd 232-4\r\n\r\n> Arch\r\n\r\nA \"failed\" service unit will still pointlessly propagate a Forward Start dependency.  This seems like the wrong thing to do, and the wrong way to be doing things.  Consider:\r\n\r\nHere is a way to add some semblance of \"hot plug\" support to the parallel printer port.\r\n\r\n---\r\n[Unit]\r\nDescription=CUPS Scheduler\r\nDocumentation=man:cupsd(8)\r\nAfter=network.target\r\nBindsTo=sys-subsystem-ppdev-devices-%i.device\r\nWants=printer.target\r\n[Service]\r\nExecStart=/usr/bin/grep -q \"CLASS:PRINTER\" /proc/sys/dev/parport/%I/autoprobe\r\n[Install]\r\nDefaultInstance=parport0\r\nWantedBy=sys-subsystem-ppdev-devices-%i.device\r\n\r\n---\r\n\r\nwhere another unit file has a WantedBy=printer.target to start cupsd.\r\n\r\nThis does not work because, despite any failure grep'ing for \"CLASS:PRINTER\", systemd will still propagate the start from sys-subsystem-ppdev-devices-%i.device to printer.target.  This would start cupsd even when there was no printer attached, which defeats the entire purpose of the unit file.\r\n\r\nIf there is some other \"canonical\" way to do this, I want to know about it.\r\n\r\nsystemd-udevd seems to have no mechanism to grep the contents of a file, and parport_pc seems not to communicate to udev or the kernel anything about its probe of any attached device.\r\n\r\nAnother alternative is to *not* use the Wants=printer.target, and to instead use:\r\n\r\n`ExecStart=/usr/bin/sh -c '/usr/bin/grep -q \"CLASS:PRINTER\"\r\n/proc/sys/dev/parport/%I/autoprobe &&\r\n/usr/bin/systemctl start printer.target'`\r\n\r\nThat works, but my understanding is that that is not \"the systemd way\".  Or, is it?  Or must it be?\r\n\r\nRegardless - what is the point of propagating a Forward Start dependency from a *failed* service unit?  *The unit **failed**.  The unit is **not** in a \"started\" state.  It cannot \"Want\" some other unit.*\r\n\r\nAnd, no, it is not a solution to go modify all the \"downstream\" unit files with Reverse dependencies on the \"upstream\" unit.  The different unit files should generally not have to know anything about each other.  Please, don't go there.\r\n"}}
{"actor":{"display_login":"poettering"}}