Without it, chef wouldn't actually start the service, concluding for some reason I haven't quite pinned down yet that the service was already running. Perhaps I didn't notice because the service would come up on reboot due to enable working (I think).
An alternative would be to bypass chef's checks and do a chef execute do command service start, but I think this is cleaner?
The matching pattern for pgrep is ^proftpd is because the server shows up as proftpd: (accepting connections) The matching against the full line(-f) in combination with ^ is needed because otherwise pgrep also matches against /etc/init.d/proftpd, which maybe is why chef was failing in the first place?
this might be affecting other metasploitable services...
Without it, chef wouldn't actually start the service, concluding for some reason I haven't quite pinned down yet that the service was already running. Perhaps I didn't notice because the service would come up on reboot due to
enable
working (I think).An alternative would be to bypass chef's checks and do a chef
execute do command service start
, but I think this is cleaner?The matching pattern for pgrep is
^proftpd
is because the server shows up asproftpd: (accepting connections)
The matching against the full line(-f
) in combination with^
is needed because otherwise pgrep also matches against/etc/init.d/proftpd
, which maybe is why chef was failing in the first place?this might be affecting other metasploitable services...